客户团队包括业务专家、产品所有者、领域专家、产品经理、业务分析师、主题专家——项目“业务”方面的每个人。客户团队编写开发团队交付的故事或功能集。他们提供的示例将以面向业务的测试形式推动编码。他们在每次迭代中与开发团队沟通和协作，回答问题，在白板上绘制示例，以及审查完成的故事或故事的一部分。

The customer team includes business experts, product owners, domain experts, product managers, business analysts, subject matter experts—everyone on the “business” side of a project. The customer team writes the stories or feature sets that the developer team delivers. They provide the examples that will drive coding in the form of business-facing tests. They communicate and collaborate with the developer team throughout each iteration, answering questions, drawing examples on the whiteboard, and reviewing finished stories or parts of stories.

测试人员是客户团队不可或缺的成员，帮助引出需求和示例，并帮助客户将他们的需求表达为测试。

Testers are integral members of the customer team, helping elicit requirements and examples and helping the customers express their requirements as tests.

参与交付代码的每个人都是开发人员，并且是开发团队的一部分。敏捷原则鼓励团队成员进行多项活动；任何团队成员都可以承担任何类型的任务。许多敏捷实践者不鼓励团队中的专门角色，并鼓励所有团队成员尽可能地将他们的技能传授给其他人。然而，每个团队都需要决定他们的项目需要什么专业知识。程序员、系统管理员、架构师、数据库管理员、技术作家、安全专家以及身兼多职的人员可能是团队的一部分，无论是物理上还是虚拟上。

Everyone involved with delivering code is a developer, and is part of the developer team. Agile principles encourage team members to take on multiple activities; any team member can take on any type of task. Many agile practitioners discourage specialized roles on teams and encourage all team members to transfer their skills to others as much as possible. Nevertheless, each team needs to decide what expertise their projects require. Programmers, system administrators, architects, database administrators, technical writers, security specialists, and people who wear more than one of these hats might be part of the team, physically or virtually.

测试人员也在开发团队中，因为测试是敏捷软件开发的核心组成部分。测试人员代表客户提倡质量，并协助开发团队实现最大的商业价值。

Testers are also on the developer team, because testing is a central component of agile software development. Testers advocate for quality on behalf of the customer and assist the development team in delivering the maximum business value.

客户和开发团队始终紧密合作。理想情况下，他们只是一个拥有共同目标的团队。该目标是为组织提供价值。敏捷项目在迭代中取得进展，迭代是通常持续一到四个星期的小开发周期。客户团队在开发人员的输入下，将确定要开发的故事的优先级，而开发团队将确定他们可以承担多少工作。他们将一起工作，通过测试和示例定义需求，并编写使测试通过的代码。测试人员涉足各个领域，了解客户的观点以及技术实施的复杂性（见图1-3）。

The customer and developer teams work closely together at all times. Ideally, they’re just one team with a common goal. That goal is to deliver value to the organization. Agile projects progress in iterations, which are small development cycles that typically last from one to four weeks. The customer team, with input from the developers, will prioritize stories to be developed, and the developer team will determine how much work they can take on. They’ll work together to define requirements with tests and examples, and write the code that makes the tests pass. Testers have a foot in each world, understanding the customer viewpoint as well as the complexities of the technical implementation (see Figure 1-3).

图1-3角色交互

Figure 1-3 Interaction of roles

一些敏捷团队没有任何成员将自己定义为“测试人员”。然而，他们都需要有人帮助客户团队为迭代的故事编写面向业务的测试，确保测试通过，并确保足够的回归测试是自动化的。即使一个团队确实有测试人员，整个敏捷团队也要负责这些测试任务。我们在敏捷团队中的经验表明，测试技能和经验对于项目成功至关重要，并且测试人员确实为敏捷团队增加了价值。

Some agile teams don’t have any members who define themselves as “testers.” However, they all need someone to help the customer team write business-facing tests for the iteration’s stories, make sure the tests pass, and make sure that adequate regression tests are automated. Even if a team does have testers, the entire agile team is responsible for these testing tasks. Our experience with agile teams has shown that testing skills and experience are vital to project success and that testers do add value to agile teams.

与程序员密切合作或从最早阶段参与项目对我们来说都不是新鲜事。然而，我们习惯于严格执行狭义软件开发生命周期的门控阶段，从发布计划和需求定义开始，通常以匆忙的测试阶段和延迟发布结束。事实上，我们经常被推为看门人的角色，告诉业务经理，“抱歉，要求已冻结；我们可以在下一个版本中添加该功能。”

Neither working closely with programmers nor getting involved with a project from the earliest phases was new to us. However, we were used to strictly enforced gated phases of a narrowly defined software development life cycle, starting with release planning and requirements definition and usually ending with a rushed testing phase and a delayed release. In fact, we often were thrust into a gatekeeper role, telling business managers, “Sorry, the requirements are frozen; we can add that feature in the next release.”

作为质量保证团队的领导者，我们也经常被期望充当质量的守门人。我们无法控制代码的编写方式，甚至无法控制是否有任何程序员测试了他们的代码，除非通过我们个人的协作努力。我们的开发后测试阶段有望在代码完成后提高质量。我们有控制的错觉。我们通常拥有生产的关键，有时我们有权推迟发布或阻止它们继续进行。Lisa 甚至拥有“质量负责人”的称号，但实际上她只是 QA 团队的经理。

As leaders of quality assurance teams, we were also often expected to act as gatekeepers of quality. We couldn’t control how the code was written, or even if any programmers tested their code, other than by our personal efforts at collaboration. Our post-development testing phases were expected to boost quality after code was complete. We had the illusion of control. We usually had the keys to production, and sometimes we had the power to postpone releases or stop them from going forward. Lisa even had the title of “Quality Boss,” when in fact she was merely the manager of the QA team.

我们的开发周期通常很长。生产数据库软件的公司的项目可能会持续一年。Lisa 在一家互联网初创公司经历的六个月发布周期在当时看来很短，尽管冻结需求仍然是一段很长的时间。尽管有很多过程和纪律，在进入下一阶段之前努力完成一个阶段，但竞争有足够的时间领先，而且应用程序并不总是客户所期望的。

Our development cycles were generally long. Projects at a company that produced database software might last for a year. The six-month release cycles Lisa experienced at an Internet start-up seemed short at the time, although it was still a long time to have frozen requirements. In spite of much process and discipline, diligently completing one phase before moving on to the next, it was plenty of time for the competition to come out ahead, and the applications were not always what the customers expected.

传统团队专注于确保所有指定要求都在最终产品中交付。如果在最初的目标发布日期之前一切还没有准备好，发布通常会被推迟。开发团队通常不知道发布中有哪些功能，或者它们应该如何工作。个别程序员倾向于专注于代码的特定区域。测试人员研究需求文档来编写他们的测试计划，然后等待工作交付给他们进行测试。

Traditional teams are focused on making sure all the specified requirements are delivered in the final product. If everything isn’t ready by the original target release date, the release is usually postponed. The development teams don’t usually have input about what features are in the release, or how they should work. Individual programmers tend to specialize in a particular area of the code. Testers study the requirements documents to write their test plans, and then they wait for work to be delivered to them for testing.

过渡到敏捷项目的短迭代可能会产生最初的震惊和敬畏。我们怎么可能定义需求，然后在一、二、三或四个星期内测试和交付生产就绪代码？这对于拥有不同职能的独立团队的大型组织来说尤其困难，对于地理位置分散的团队来说更难。所有这些不同的程序员、测试人员、分析师、项目经理和无数专业人士在新的敏捷项目中处于什么位置？我们怎么可能这么快地编码和测试呢？我们在哪里可以找到时间来进行自动化测试等困难的工作？我们对交付到生产环境的错误代码有什么控制？

Transitioning to the short iterations of an agile project might produce initial shock and awe. How can we possibly define requirements and then test and deliver production-ready code in one, two, three, or four weeks? This is particularly tough for larger organizations with separate teams for different functions and even harder for teams that are geographically dispersed. Where do all these various programmers, testers, analysts, project managers, and countless specialties fit in a new agile project? How can we possibly code and test so quickly? Where would we find time for difficult efforts such as automating tests? What control do we have over bad code getting delivered to production?

我们将分享我们第一次敏捷体验的故事，向您展示每个人都必须从某个地方开始。

We’ll share our stories from our first agile experiences to show you that everyone has to start somewhere.

敏捷团队与业务紧密合作，对需求有详细的了解。他们专注于他们可以提供的价值，并且他们可能对确定功能的优先级有大量的投入。测试人员不会坐等工作；他们站起来寻找在整个开发周期及以后做出贡献的方法。

Agile teams work closely with the business and have a detailed understanding of the requirements. They’re focused on the value they can deliver, and they might have a great deal of input into prioritizing features. Testers don’t sit and wait for work; they get up and look for ways to contribute throughout the development cycle and beyond.

如果对敏捷项目的测试感觉就像对传统项目的测试一样，我们就不会觉得有必要写一本书了。让我们比较和对比这些测试方法。

If testing on an agile project felt just like testing on a traditional project, we wouldn’t feel the need to write a book. Let’s compare and contrast these testing methods.

它有助于从查看敏捷测试与传统软件开发中的测试之间的相似性开始。考虑图 1-4。

It helps to start by looking at similarities between agile testing and testing in traditional software development. Consider Figure 1-4.

图 1-4传统测试与敏捷测试

Figure 1-4 Traditional testing vs. agile testing

在分阶段方法图中，很明显测试发生在最后，就在发布之前。该图是理想化的，因为它给人的印象是，用于测试的时间与用于编码的时间一样多。在许多项目中，情况并非如此。测试被“压缩”了，因为编码花费的时间比预期的要长，而且团队最终进入了编码和修复的循环。

In the phased approach diagram, it is clear that testing happens at the end, right before release. The diagram is idealistic, because it gives the impression there is as much time for testing as there is for coding. In many projects, this is not the case. The testing gets “squished” because coding takes longer than expected, and because teams get into a code-and-fix cycle at the end.

敏捷是迭代和增量的。这意味着测试人员会在编码完成后立即测试每个编码增量。一次迭代可能短至一周，也可能长至一个月。该团队构建并测试了一些代码，确保其正常工作，然后继续进行下一个需要构建的部分。程序员永远不会领先于测试人员，因为一个故事只有经过测试才算“完成”。我们将在整本书中更多地讨论这一点。

Agile is iterative and incremental. This means that the testers test each increment of coding as soon as it is finished. An iteration might be as short as one week, or as long as a month. The team builds and tests a little bit of code, making sure it works correctly, and then moves on to next piece that needs to be built. Programmers never get ahead of the testers, because a story is not “done” until it has been tested. We’ll talk much more about this throughout the book.

敏捷团队采用的项目方法多种多样。一个团队可能专注于一个项目，也可能是另一个项目的一部分更大的项目。无论您的项目有多大，您仍然需要从某个地方开始。您的团队可能会在估算会议上处理一个史诗或功能，一组相关的故事，或者您可能会开会计划发布。无论项目或项目的子集是如何开始的，您都需要对其有一个高层次的理解。在准备发布时，您可能会想出一个测试计划或策略，但它可能看起来与您之前完成的任何测试计划都大不相同。

There’s tremendous variety in the approaches to projects that agile teams take. One team might be dedicated to a single project or might be part of another bigger project. No matter how big your project is, you still have to start somewhere. Your team might take on an epic or feature, a set of related stories at an estimating meeting, or you might meet to plan the release. Regardless of how a project or subset of a project gets started, you’ll need to get a high-level understanding of it. You might come up with a plan or strategy for testing as you prepare for a release, but it will probably look quite different from any test plan you’ve done before.

每个项目、每个团队，有时甚至每个迭代都是不同的。你的团队如何解决问题应该取决于问题、人员和你可用的工具。作为敏捷团队成员，您需要适应团队的需求。

Every project, every team, and sometimes every iteration is different. How your team solves problems should depend on the problem, the people, and the tools you have available. As an agile team member, you will need to be adaptive to the team’s needs.

与其根据业务分析师在任何人想到编写一行代码之前创建的需求文档创建测试，不如有人需要在编码开始前几天或几小时编写测试来说明每个故事的需求。这通常是一个团队之间的协作努力业务或领域专家以及测试人员、分析师或其他开发团队成员。详细的功能测试用例，最好基于业务专家提供的示例，充实需求。测试人员将进行手动探索性测试，以发现定义的测试用例可能遗漏的重要错误。随着对每个故事的编码进行，测试人员可能会与其他开发人员配对以自动化和执行测试用例。自动功能测试被添加到回归测试套件中。当演示最小功能的测试完成时，团队可以认为故事已经完成。

Rather than creating tests from a requirements document that was created by business analysts before anyone ever thought of writing a line of code, someone will need to write tests that illustrate the requirements for each story days or hours before coding begins. This is often a collaborative effort between a business or domain expert and a tester, analyst, or some other development team member. Detailed functional test cases, ideally based on examples provided by business experts, flesh out the requirements. Testers will conduct manual exploratory testing to find important bugs that defined test cases might miss. Testers might pair with other developers to automate and execute test cases as coding on each story proceeds. Automated functional tests are added to the regression test suite. When tests demonstrating minimum functionality are complete, the team can consider the story finished.

如果你参加过本世纪初的敏捷会议和研讨会，你会听到很多关于 TDD 和验收测试的信息，但很少听到其他关键类型的测试，例如负载、性能、安全性、可用性和其他“能力”测试。作为测试人员，我们认为这有点奇怪，因为所有这些类型的测试对于敏捷项目和使用任何其他开发方法的项目一样重要。真正的区别在于，我们喜欢在开发过程中尽早进行这些测试，以便它们也可以驱动设计和编码。

If you attended agile conferences and seminars in the early part of this decade, you heard a lot about TDD and acceptance testing but not so much about other critical types of testing, such as load, performance, security, usability, and other “ility” testing. As testers, we thought that was a little weird, because all these types of testing are just as vital on agile projects as they are on projects using any other development methodology. The real difference is that we like to do these tests as early in the development process as we can so that they can also drive design and coding.

如果团队像 Lisa 的团队那样实际发布每个迭代，则每个迭代的最后一两天就是“结束游戏”，此时可以进行用户验收测试、培训、错误修复和部署到暂存环境。其他团队，例如 Janet 的团队，每隔几次迭代就发布一次，甚至可能有整个迭代的“结束游戏”活动来验证发布准备情况。这里的区别是所有的测试都没有留到最后。

If the team actually releases each iteration, as Lisa’s team does, the last day or two of each iteration is the “end game,” the time when user acceptance testing, training, bug fixing, and deployments to staging environments can occur. Other teams, such as Janet’s, release every few iterations, and might even have an entire iteration’s worth of “end game” activities to verify release readiness. The difference here is that all the testing is not left until the end.

作为敏捷团队的测试人员，您是将代码发布到生产环境的关键角色，就像您在更传统的环境中一样。您可能会运行脚本或进行手动测试以验证发布的所有元素（例如数据库更新脚本）是否就位。所有团队成员都参与可能针对每次迭代或每次发布进行的回顾或其他流程改进活动。整个团队集思广益解决问题并改进流程和实践的方法。

As a tester on an agile team, you’re a key player in releasing code to production, just as you might have been in a more traditional environment. You might run scripts or do manual testing to verify all elements of a release, such as database update scripts, are in place. All team members participate in retrospectives or other process improvement activities that might occur for every iteration or every release. The whole team brainstorms ways to solve problems and improve processes and practices.

敏捷项目有多种风格。您的团队是否在全新的（新）开发项目中从头开始？如果是这样，与在没有自动回归套件的遗留系统上重写或构建的团队相比，您面临的挑战可能更少。与第三方合作会给任何团队带来额外的测试挑战。

Agile projects have a variety of flavors. Is your team starting with a clean slate, in a greenfield (new) development project? If so, you might have fewer challenges than a team faced with rewriting or building on a legacy system that has no automated regression suite. Working with a third party brings additional testing challenges to any team.

无论您使用哪种开发方式，软件开发生命周期中几乎相同的元素都需要发生。区别敏捷的特点是时间框架大大缩短，活动同时发生。参与者、测试和工具需要具有适应性。

Whatever flavor of development you’re using, pretty much the same elements of a software development life cycle need to happen. The difference with agile is that time frames are greatly shortened, and activities happen concurrently. Participants, tests, and tools need to be adaptive.

敏捷项目中测试人员最关键的区别是来自测试的快速反馈。它推动项目向前发展，如果未达到某些里程碑，没有守门人准备阻止项目进展。

The most critical difference for testers in an agile project is the quick feedback from testing. It drives the project forward, and there are no gatekeepers ready to block project progress if certain milestones aren’t met.

我们遇到过抵制向敏捷开发过渡的测试人员，他们担心“敏捷开发”等同于混乱、缺乏纪律、缺乏文档以及对测试人员不利的环境。虽然一些团队似乎确实使用“敏捷”这个流行语来证明他们想做什么就做什么，但真正的敏捷团队都是关于可重复的质量和效率。根据我们的经验，敏捷团队是测试人员的绝佳去处。

We’ve encountered testers who resist the transition to agile development, fearing that “agile development” equates with chaos, lack of discipline, lack of documentation, and an environment that is hostile to testers. While some teams do seem to use the “agile” buzzword to justify simply doing whatever they want, true agile teams are all about repeatable quality as well as efficiency. In our experience, an agile team is a wonderful place to be a tester.

鉴于测试驱动敏捷项目，反馈在任何敏捷团队中都起着重要作用也就不足为奇了。测试人员作为“信息提供者”的传统角色使她对敏捷团队具有内在的价值。敏捷测试人员最重要的贡献之一是帮助产品所有者或客户以示例和测试的形式阐明每个故事的需求。然后，测试人员与队友一起工作，将这些需求转化为可执行的测试。测试人员、程序员和其他团队成员尽早并经常运行这些测试，以便他们不断得到有意义的反馈的指导。我们将在本书中花大量时间解释如何做到这一点。

Given that tests drive agile projects, it’s no surprise that feedback plays a big part in any agile team. The tester’s traditional role of “information provider” makes her inherently valuable to an agile team. One of the agile tester’s most important contributions is helping the product owner or customer articulate requirements for each story in the form of examples and tests. The tester then works together with teammates to turn those requirements into executable tests. Testers, programmers, and other team members work to run these tests early and often so they’re continually guided by meaningful feedback. We’ll spend a lot of time in this book explaining ways to do this.

当团队遇到障碍时，反馈是帮助消除障碍的一种方式。我们是否提供了一个不能完全满足客户期望的用户界面？让我们写一张任务卡，提醒我们在下一个 UI 故事的纸质原型上与客户合作。

When the team encounters obstacles, feedback is one way to help remove them. Did we deliver a user interface that didn’t quite meet customer expectations? Let’s write a task card reminding us to collaborate with the customer on paper prototypes of the next UI story.

管理层是否担心工作的进展情况？显示每天编写、运行和通过的测试的大图表。显示大图功能覆盖范围，例如测试矩阵。难以使构建稳定？Lisa 的团队显示了距离标记要发布的版本还有多少天，以便让每个人都专注于及时完成故事。在这成为一种习惯之后，他们就不再需要视觉提示了。

Is management worried about how work is progressing? Display a big visible chart of tests written, run, and passing every day. Display big-picture functionality coverage such as test matrices. Having trouble getting the build stable? Lisa’s team displayed the number of days remaining until time to tag the build for release in order to keep everyone focused on finishing stories in time. After that became a habit, they didn’t need the visual cue anymore.

敏捷开发是关于在提供客户最近优先考虑的功能的小版本中交付价值。这通常意味着限制范围。很容易被客户吸引团队对酷功能的渴望。任何人都可以质疑这些添加，但测试人员通常会认识到对故事的影响，因为他们需要考虑测试的影响。

Agile development is about delivering value in small releases that provide exactly the functionality that the customer has most recently prioritized. This usually means limiting scope. It’s easy to get caught up in the customer team’s desire for cool features. Anyone can question these additions, but a tester often recognizes the impact to the story, because they need to think about the testing repercussions.

敏捷测试人员始终专注于大局。我们可以在此迭代中交付最关键的功能，并在以后添加。如果我们让新功能潜入，我们就有可能无法按时交付任何东西。如果我们过于关注边缘案例而错过了快乐道路上的核心功能，我们将无法提供业务所需的价值。

Agile testers stay focused on the big picture. We can deliver the most critical functionality in this iteration and add to it later. If we let new features creep in, we risk delivering nothing on time. If we get too caught up with edge cases and miss core functionality on the happy path, we won’t provide the value the business needs.

敏捷测试人员采用与 Lisa 的故事中确定的方法相同的方法。虽然我们的一项技能是识别“快乐路径”之外的测试用例，但我们仍然需要从确保快乐路径有效开始。我们可以为快乐路径自动化测试，并在以后添加负面和边界测试。始终考虑什么能为客户增加最大价值，并了解您的背景。如果应用程序是安全关键的，则绝对需要添加负面测试。在估算过程中需要考虑测试时间，以确保在迭代中分配足够的时间来交付“安全”功能。

Agile testers take the same approach as that identified in Lisa’s story. While one of our skills is to identify test cases beyond the “happy path,” we still need to start by making sure the happy path works. We can automate tests for the happy path, and add negative and boundary tests later. Always consider what adds the most value to the customer, and understand your context. If an application is safety-critical, adding negative tests is absolutely required. The testing time needs to be considered during the estimation process to make sure that enough time is allotted in the iteration to deliver a “safe” feature.

没有良好的沟通，任何团队都无法运作良好。今天，当这么多团队分布在多个地理位置时，沟通是甚至更重要，更具挑战。敏捷测试人员应该寻找促进沟通的独特方式。这是做好她工作的一个关键方面。

No team works well without good communication. Today, when so many teams are distributed in multiple geographical locations, communication is even more vital and more of a challenge. The agile tester should look for unique ways to facilitate communication. It is a critical aspect to doing her job well.

任何时候出现关于功能应该如何工作或界面应该是什么样子的问题时，测试人员都可以召集程序员和业务专家来讨论。测试人员永远不应该妨碍任何直接的客户与开发人员的沟通，但他们通常可以帮助确保沟通的发生。

Any time there is a question about how a feature should work or what an interface should look like, the tester can pull in a programmer and a business expert to talk about it. Testers should never get in the way of any direct customer-developer communication, but they can often help to make sure that communication happens.

敏捷测试人员从客户的角度看待每个故事或主题，但也了解与实现功能相关的技术方面和限制。他们可以帮助客户和开发人员实现共同语言。业务人员和软件人员经常说不同的语言。他们必须找到一些共同点才能成功合作。测试人员可以帮助他们开发一种共享语言、项目方言或团队行话。

Agile testers see each story or theme from the customer’s point of view but also understand technical aspects and limitations related to implementing features. They can help customers and developers achieve a common language. Business people and software people often speak different languages. They have to find some common ground in order to work together successfully. Testers can help them develop a shared language, a project dialect, or team jargon.

Brian Marick (2003) 建议我们使用示例来开发这种语言。当 Lisa 的团队在冲刺计划会议期间进行哲学讨论时，Lisa 向产品负责人询问示例或使用场景。测试人员可以通过更多示例鼓励白板讨论。这些有助于客户更清楚地设想他们的要求。它们还帮助开发人员生成设计良好的代码以满足这些要求。

Brian Marick (2003) recommends that we use examples to develop this language. When Lisa’s team digresses into a philosophical discussion during a sprint planning meeting, Lisa asks the product owner for an example or usage scenario. Testers can encourage whiteboard discussions to work through more examples. These help the customers envision their requirements more clearly. They also help the developers to produce well-designed code to meet those requirements.

面对面的交流无可替代。敏捷开发依赖于持续的协作。与其他敏捷团队成员一样，执行测试任务的人员将不断寻找客户和技术团队成员进行讨论和协作。当敏捷测试人员怀疑隐藏的假设或被误解的需求时，她会让客户和开发人员讨论它。如果不同建筑物或大陆的人们需要交谈，他们会寻找创造性的方式来取代面对面的实时对话。

Face-to-face communication has no substitute. Agile development depends on constant collaboration. Like other agile team members, the people doing testing tasks will continually seek out customer and technical team members to discuss and collaborate. When an agile tester suspects a hidden assumption or a misunderstood requirement, she’ll get a customer and a developer talking about it. If people in a different building or continent need to talk, they look for creative ways to replace face-to-face, real-time conversations.

勇气是 XP 中的核心价值，测试自动化和持续集成等实践让团队践行这一价值。开发人员有勇气进行更改和重构代码，因为他们拥有自动回归套件的安全网。在本节中，我们将讨论过渡到敏捷团队时所需的情感勇气。

Courage is a core value in XP, and practices such as test automation and continuous integration allow the team to practice this value. The developers have the courage to make changes and refactor the code because they have the safety net of an automated regression suite. In this section, we talk about the emotional courage that is needed when transitioning to an agile team.

您是否曾在一个组织中工作，测试人员被困在自己的孤岛中，无法与业务利益相关者或技术团队的其他成员交谈？虽然您可能会抓住机会加入协作敏捷环境，但您可能会觉得不得不去询问客户示例，或者要求程序员帮助自动化测试或在每日站立会议中提出障碍，这让您感到不自在。

Have you worked in an organization where testers were stuck in their own silo, unable to talk to either business stakeholders or other members of the technical team? While you might jump at the chance to join a collaborative agile environment, you might feel uncomfortable having to go ask the customer for examples, or ask a programmer to help automate a test or bring up a roadblock during the daily stand-up.

当您第一次加入敏捷团队时，或者当您当前的团队第一次过渡到敏捷开发时，感到恐惧并列出需要回答的问题列表是很正常的。这么短的时间，我们要如何完成每个故事的测试任务？测试将如何“跟上”开发？你怎么知道多少测试就足够了？或者，您可能是一名功能测试经理或质量流程经理，您不清楚该角色在敏捷团队中的位置，而且没有人知道答案。敏捷测试人员需要勇气来找到这些问题的答案，但也有其他需要勇气的原因。

When you first join an agile team, or when your current team firsts transitions to agile development, it’s normal to experience fear and have a list of questions that need to be answered. How in the world are we going to be able to complete testing tasks for each story in such a short time? How will testing “keep up” with development? How do you know how much testing is enough? Or maybe you’re a functional testing manager or a quality process manager and it’s not clear to you where that role fits on an agile team, and nobody has the answers. Agile testers need courage to find the answers to those questions, but there are other reasons as well for having courage.

我们需要勇气让自己失败，知道至少我们会很快失败并能够从失败中吸取教训。在我们因为没有获得稳定的构建而导致迭代失败后，我们将开始考虑确保它不会再次发生的方法。

We need courage to let ourselves fail, knowing that at least we’ll fail fast and be able to learn from that failure. After we’ve blown an iteration because we didn’t get a stable build, we’ll start thinking of ways to ensure it doesn’t happen again.

我们需要勇气允许别人犯错，因为这是吸取教训的唯一途径。

We need courage to allow others to make mistakes, because that’s the only way to learn the lesson.

我们需要勇气寻求帮助，尤其是当可以提供帮助的人看起来非常忙碌而且压力很大时。走出你的旧筒仓并加入一个团队来为成功或失败负责需要勇气。提出问题或指出您认为的缺陷需要勇气，即使在一个由敏捷价值观和原则支持的团队中也是如此。不要害怕！敏捷团队是开放的，通常接受新想法。

We need courage to ask for help, especially when the person who could provide that help looks pretty busy and stressed-out himself. Climbing out of your old silo and joining in a team responsibility for success or failure takes courage. Asking a question or pointing out what you think is a flaw requires courage, even in a team supported by agile values and principles. Don’t be afraid! Agile teams are open and generally accepting of new ideas.

Kent Beck 的Extreme Programming Explained建议我们做可能可行的最简单的事情。这并不意味着您尝试的第一件事实际上会起作用，但它应该很简单。

Kent Beck’s Extreme Programming Explained advised us to do the simplest thing that could possibly work. That doesn’t mean the first thing you try will actually work, but it ought to be simple.

敏捷测试人员及其团队面临的挑战不仅是要生成最简单的软件实现，还要采取简单的方法来确保软件满足客户需求。这并不意味着团队不应该花一些时间来分析主题和故事并思考适当的架构和设计。这确实意味着当他们的需求可能有点复杂并且更简单的解决方案将提供相同的价值时，团队可能需要将其推回到团队的业务方面。

Agile testers and their teams are challenged to not only produce the simplest possible software implementation but to take a simple approach to ensuring that software meets the customer requirements. This doesn’t mean that the team shouldn’t take some time to analyze themes and stories and think through the appropriate architecture and design. It does mean that the team might need to push back to the business side of the team when their requirements might be a bit elaborate and a simpler solution will deliver the same value.

我们中的一些人在软件组织工作，作为测试人员和质量保证人员，我们被要求制定质量标准。我们认为这是倒退的，因为这取决于客户团队来决定他们想要支付什么样的质量水平。测试人员和其他团队成员应该向客户提供信息并帮助他们考虑质量的所有方面，包括性能和安全性等非功能性需求。最终决定取决于客户。团队可以通过采取简单的、循序渐进的方法来帮助客户做出正确的决定。敏捷测试手段进行尽可能简单的测试以验证某项功能是否存在或是否满足客户的质量标准（例如，性能）。

Some of us worked in software organizations where we, as testers and quality assurance staff, were asked to set quality standards. We believe this is backwards, because it’s up to the customer team to decide what level of quality they want to pay for. Testers and other team members should provide information to customers and help them consider all aspects of quality, including nonfunctional requirements such as performance and security. The ultimate decisions are up to the customer. The team can help the customer make good decisions by its taking a simple, step-by-step approach to its work. Agile testing means doing the simplest tests possible to verify that a piece of functionality exists or that the customer’s quality standard (e.g., performance) has been met.

简单并不意味着容易。对于测试人员来说，这意味着使用我们能找到的最轻量级的工具和技术来测试“刚好足够”，以完成这项工作。工具可以像电子表格或清单一样简单。我们需要自动化回归测试，但我们应该将它们降低到尽可能低的级别，以鼓励快速反馈。即使是简单的冒烟测试也可能足以实现面向业务的测试自动化。

Simple doesn’t mean easy. For testers, it means testing “just enough” with the lightest-weight tools and techniques we can find that will do the job. Tools can be as simple as a spreadsheet or a checklist. We need to automate regression tests, but we should push them down to the lowest level possible in order to encourage fast feedback. Even simple smoke tests might be enough for business-facing test automation.

探索性测试可用于了解您的应用程序并找出难以发现的错误，但要从基础知识、时间限制的旁路测试和评估边缘案例的进展情况开始。简单有助于我们将注意力集中在风险、投资回报和改进最痛苦的领域。

Exploratory testing can be used to learn about your application and ferret out hard-to-find bugs, but start with the basics, time-boxing side trips and evaluating how far to go with edge cases. Simplicity helps us keep our focus on risk, return on investment, and improving in the areas of greatest pain.

寻找方法来做得更好是敏捷测试人员心态的一部分。当然，整个团队都应该这样想，因为敏捷的中心核心是团队总是努力把工作做得更好。测试人员参与团队回顾，评估哪些运作良好，哪些需要添加或调整。测试人员将测试问题提交给整个团队来解决。团队通过使用过程改进实践（例如回顾和障碍积压）在测试和所有其他领域取得了最大的改进。一些改进想法可能会成为任务卡。对于更大的问题，团队一次只关注一两个问题，以确保他们解决了真正的问题，而不仅仅是表面现象。

Looking for ways to do a better job is part of an agile tester’s mind-set. Of course, the whole team should be thinking this way, because the central core of agile is that the team always tries to do better work. Testers participate in team retrospectives, evaluating what’s working well and what needs to be added or tweaked. Testers bring testing issues up for the whole team to address. Teams have achieved their greatest improvements in testing and all other areas through the use of process improvement practices such as retrospectives and impediment backlogs. Some improvement ideas might become task cards. For larger problems, teams focus on one or two issues at a time to make sure they solve the real problem and not just the symptom.

敏捷测试人员和他们的团队总是在寻找可以帮助他们增加更多价值或获得更好的客户投资回报的工具、技能或实践。敏捷开发的短迭代使得在几次迭代中尝试新事物变得更容易，并且看看它是否值得长期采用。

Agile testers and their teams are always on the lookout for tools, skills, or practices that might help them add more value or get a better return on the customer’s investment. The short iterations of agile development make it easier to try something new for a few iterations and see whether it’s worth adopting for the long term.

学习新技能和专业成长对敏捷测试人员来说很重要。他们利用许多可用的免费资源来提高他们的专业技能，例如探索性测试。他们参加各种会议、加入邮件列表、阅读文章、博客和书籍以获得新想法。他们寻找自动化（或从同事那里获得帮助以自动化）平凡或重复性任务的方法，以便他们有更多时间贡献他们宝贵的专业知识。

Learning new skills and growing professionally are important to agile testers. They take advantage of the many available free resources to improve their specialized skills, such as exploratory testing. They go to meetings and conferences, join mailing lists, and read articles, blogs, and books to get new ideas. They look for ways to automate (or get help from their coworkers to automate) mundane or repetitive tasks so they have more time to contribute their valuable expertise.

Pierre Veragren 是 iLevel by Weyerhaeuser 的 SQA 负责人，他发现了我们自己在敏捷团队中经常看到的一种品质：“AADD”，即敏捷注意力缺陷障碍。任何不能快速学习的东西都可能被认为是无用的。敏捷团队成员寻求投资回报，如果他们没有很快看到回报，他们就会继续前进。当您每两周甚至更频繁地交付生产就绪软件时，这并不是一个负面特征。

Pierre Veragren, an SQA Lead at iLevel by Weyerhaeuser, identified a quality we often see in agile teams ourselves: “AADD,” Agile Attention Deficit Disorder. Anything not learned quickly might be deemed useless. Agile team members look for return on investment, and if they don’t see it quickly, they move on. This isn’t a negative characteristic when you’re delivering production-ready software every two weeks or even more often.

回顾是一种关键的敏捷实践，它可以让团队利用昨天的经验在明天做得更好。敏捷测试人员利用这个机会提出与测试相关的问题，并要求团队集思广益解决这些问题。这是团队向自己提供反馈以持续改进的一种方式。

Retrospectives are a key agile practice that lets the team use yesterday’s experience to do a better job tomorrow. Agile testers use this opportunity to raise testing-related issues and ask the team to brainstorm ways to address them. This is a way for the team to provide feedback to itself for continual improvement.

当我们在瀑布环境中工作时，我们习惯于说，“对不起，我们现在不能做这个改变；要求被冻结。我们必须把它放在第一个补丁版本中。” 这让客户感到沮丧，因为他们意识到他们没有很好地预先定义所有需求。

When we worked in a waterfall environment, we got used to saying, “Sorry, we can’t make this change now; the requirements are frozen. We’ll have to put that in the first patch release.” It was frustrating for customers because they realized that they didn’t do a great job on defining all their requirements up front.

在为期两周的敏捷迭代中，我们可能不得不说，“好吧，为此写一张卡片，我们将在下一次迭代或下一次发布中完成，”但客户知道他们可以在需要时获得更改，因为他们控制优先级。

In a two-week agile iteration, we might have to say, “OK, write a card for that and we’ll do it in the next iteration or next release,” but customers know they can get their change when they want it because they control the priority.

响应变化是敏捷实践者的一个关键价值，但我们发现它是测试人员最难理解的概念之一。稳定性是测试人员所渴望的，这样他们就可以说，“我已经测试过了；我已经测试过了；” 完成。” 不断变化的需求是测试人员的噩梦。但是，作为敏捷测试人员，我们必须欢迎变化。周三，我们可能会开始故事 A 和 B然后下周五 C。到周五，客户可能已经重新确定优先级，现在想要故事 A、X 和 Y。只要我们继续与客户交谈，我们就可以处理这样的变化，因为我们与团队其他成员的工作节奏相同.

Responding to change is a key value for agile practitioners, but we’ve found that it’s one of the most difficult concepts for testers. Stability is what testers crave so that they can say, “I’ve tested that; it’s done.” Continuously changing requirements are a tester’s nightmare. However, as agile testers, we have to welcome change. On Wednesday, we might expect to start stories A and B and then C the next Friday. By Friday, the customer could have re-prioritized and now wants stories A, X, and Y. As long as we keep talking to the customer, we can handle changes like that because we are working at the same pace with the rest of team.

一些敏捷团队尝试在下一次迭代之前做好准备，可能是通过编写高级测试用例、捕获业务满意度条件或记录示例。这是一项棘手的工作，如果重新确定故事的优先级或进行重大更改，可能会导致时间浪费。然而，分布式团队尤其需要额外的反馈周期来为迭代做好准备。

Some agile teams try to prepare in advance of the next iteration, perhaps by writing high-level test cases, capturing business satisfaction conditions, or documenting examples. It’s a tricky business that might result in wasted time if stories are re-prioritized or greatly changed. However, distributed teams in particular need extra feedback cycles to get ready for the iteration.

有些团队有分析师，他们可以花更多时间与业务专家一起做一些预先计划。每个团队都必须在提前集思广益解决方案和在每次迭代的第一天从头开始之间取得平衡。敏捷测试人员顺应潮流并与团队合作以适应变化。

Some teams have analysts who can spend more time with the business experts to do some advance planning. Each team has to strike a balance between brainstorming solutions ahead of time and starting from scratch on the first day of each iteration. Agile testers go with the flow and work with the team to accommodate changes.

自动化测试是解决方案的关键之一。我们可以肯定地知道一件事：没有任何敏捷团队仅通过手动测试就能成功。我们需要强大的自动化，以便在使其有价值的时间范围内交付业务价值。

Automated testing is one key to the solution. One thing we know for sure: No agile team will succeed doing only manual testing. We need robust automation in order to deliver business value in a time frame that makes it valuable.

敏捷测试人员是自组织敏捷团队的一部分。团队文化灌输了敏捷测试理念。当程序员、系统管理员、分析师、数据库专家和客户团队不断思考测试和测试自动化时，测试人员就会享受到全新的视角。自动化测试很难，但当你拥有整个团队时，它会容易得多一起工作。当您有具有多种技能和多种观点的人来攻击它时，任何测试问题都更容易解决。

The agile tester is part of a self-organizing agile team. The team culture imbues the agile testing philosophy. When programmers, system administrators, analysts, database experts, and the customer team think continually about testing and test automation, testers enjoy a whole new perspective. Automating tests is hard, but it is much easier when you have the whole team working together. Any testing issue is easier to address when you have people with multiple skill sets and multiple perspectives attacking it.

当一个敏捷团队面临一个大问题时，也许是生产停滞或构建失败，这是每个人的问题。最高优先级的问题是整个团队要解决的问题。团队成员立即讨论问题并决定如何解决以及由谁来解决。

When an agile team faces a big problem, perhaps a production showstopper or a broken build, it’s everyone’s problem. The highest-priority issues are problems for the whole team to solve. Team members discuss the issue right away and decide how to and who will fix it.

毫无疑问，Lisa 的经理可以要求团队采用这种方法来解决其自动化问题，但团队自己可以提出最可行的计划。当团队创建自己的方法并致力于它时，其成员就会对测试采取新的态度。

There’s no doubt that Lisa’s manager could have mandated that the team take this approach to solving its automation problems, but the team itself can come up with the most workable plan. When the team creates its own approach and commits to it, its members adopt a new attitude toward testing.

当好人被允许做他们最好的工作时，项目就会成功。敏捷价值观和原则的创建旨在实现个人和团队的成功。敏捷团队成员应该感到安全，不必担心因错误而受到指责或失去工作。敏捷团队成员相互尊重并认可个人成就。敏捷团队中的每个人都应该有机会成长和发展他们的技能。敏捷团队以可持续的步伐工作，使他们能够遵循纪律严明的做法并保持全新的视角。正如敏捷宣言所述，我们重视个人和交互胜过流程和工具。

Projects succeed when good people are allowed to do their best work. Agile values and principles were created with the aim of enabling individual and team success. Agile team members should feel safe and not have to worry about being blamed for mistakes or losing their jobs. Agile team members respect each other and recognize individual accomplishments. Everyone on an agile team should have opportunities to grow and develop their skills. Agile teams work at a sustainable pace that lets them follow disciplined practices and keep a fresh perspective. As the Agile Manifesto states, we value individuals and interactions over processes and tools.

在软件开发的历史中，测试人员并不总是享有与开发团队中其他角色同等的地位。有些人将测试人员视为失败的程序员或软件开发领域的二等公民。懒得学习新技能和专业成长的测试人员会导致人们认为测试是一项低技能工作。甚至连“测试员”这个词也被避免了，优先使用“质量保证工程师”或“质量分析师”等职位以及“QA 部门”等团队名称。

In the history of software development, testers haven’t always enjoyed parity with other roles on the development team. Some people saw testers as failed programmers or second-class citizens in the world of software development. Testers who don’t bother to learn new skills and grow professionally contribute to the perception that testing is low-skilled work. Even the term “tester” has been avoided, with job titles such as “Quality Assurance Engineer” or “Quality Analyst” and team names such as “QA Department” given preference.

坚持真正敏捷哲学的敏捷团队给予所有团队成员同等的权重。敏捷测试人员知道他们为他们的团队贡献了独特的价值，而开发团队发现当他们的团队包括具有特定测试技能和背景的人时，他们会更加成功。例如，熟练的探索性测试人员可能会发现系统中无法通过自动功能测试检测到的问题。具有深厚测试经验的人可能会提出重要的问题，而这些问题对于没有测试经验的团队成员来说是不会想到的。测试知识是任何团队交付价值能力的组成部分之一。

Agile teams that adhere to the true agile philosophy give all team members equal weight. Agile testers know they contribute unique value to their teams, and development teams have found they are more successful when their team includes people with specific testing skills and background. For example, a skilled exploratory tester may discover issues in the system that couldn’t be detected by automated functional tests. Someone with deep testing experience might ask important questions that didn’t occur to team members without testing experience. Testing knowledge is one component of any team’s ability to deliver value.

在一个每个人都协作的团队中工作，你从头到尾参与项目，业务利益相关者与开发团队一起工作，整个团队负责质量和测试，在我们看来，这简直就是测试者的乌托邦。我们并不是唯一相信每个人都应该在工作中找到乐趣的人。敏捷开发奖励敏捷测试人员对其工作的热情。

Working on a team where everyone collaborates, where you are engaged in the project from start to finish, where business stakeholders work together with the development team, where the whole team takes responsibility for quality and testing, in our opinion, is nothing short of a tester’s Utopia. We’re not alone in believing that everyone should find joy in their work. Agile development rewards the agile tester’s passion for her work.

我们作为敏捷测试人员的工作特别令人满意，因为我们的观点和技能让我们能够为我们的团队增加真正的价值。在下一节中，我们将探讨如何。

Our jobs as agile testers are particularly satisfying because our viewpoint and skills let us add real value to our teams. In the next section, we’ll explore how.

从组织如何确定可接受的软件质量水平的角度考虑组织的质量理念。它能容忍质量差吗？它是否考虑了客户的质量要求，还是只关心尽快将产品送到客户手中？

Consider an organization’s quality philosophy in terms of how it determines the acceptable level of software quality. Does it tolerate poor quality? Does it take customers’ quality requirements into account, or is it just concerned with getting the product into the customers’ hands as fast as it can?

当一个组织缺乏整体质量理念并迫使团队在不考虑质量的情况下推出产品时，测试人员会感到压力。试图在这样的环境中使用敏捷开发的团队面临着一场艰苦的战斗。

When an organization lacks an overall quality philosophy and pressures teams to get the product out without regard to quality, testers feel the pinch. A team that tries to use agile development in such an environment faces an uphill battle.

一些组织拥有强大的、独立的测试团队，他们拥有很大的权力。这些团队及其经理可能认为敏捷开发会夺走这种力量。他们可能担心敏捷与他们的质量理念背道而驰。评估您组织的质量理念和执行它的团队的理念。

Some organizations have strong, independent test teams that wield a lot of power. These teams, and their managers, might perceive that agile development will take that power away. They might fear that agile runs contrary to their quality philosophy. Evaluate your organization’s quality philosophy and the philosophy of the teams that enforce it.

每个人都重视质量的公司将更容易过渡到敏捷。如果任何一个团队承担了质量责任，他们就必须学会与团队中的其他人分享这一点才能取得成功。

Companies in which everyone values quality will have an easier time transitioning to agile. If any one group has assumed ownership of quality, they’ll have to learn to share that with everyone else on the team in order to succeed.

传统的测试团队习惯于在项目结束时进行快速而激烈的测试，这转化为周末和​​晚上的工作。在这个项目结束测试阶段，一些组织定期要求他们的团队每周投入 50、60 或更多小时来努力赶上最后期限。组织通常将加班时间视为衡量个人承诺的标准。这与敏捷价值观相冲突，敏捷价值观围绕着让人们始终把工作做到最好。

Traditional test teams are accustomed to fast and furious testing at the end of a project, which translates into working weekends and evenings. During this end-of-project testing phase, some organizations regularly ask their teams to put in 50, 60, or more hours each week to try to meet a deadline. Organizations often look at overtime as a measure of an individual’s commitment. This conflicts with agile values that revolve around enabling people to do their best work all the time.

在敏捷项目中，我们鼓励您以可持续的速度工作。这意味着团队以一致的速度工作，保持恒定的速度，从而保持高质量标准。新的敏捷团队往往对他们可以完成的事情过于乐观，并且报名参加了太多的工作。经过一两次迭代后，他们学会了注册足够的工作，因此不需要加班来完成他们的任务。每周工作 40 小时是 XP 团队正常的可持续发展速度；如果一周又一周地付出努力，人们就可以在长期内完成最多的工作，同时交付良好的价值。

In agile projects, you are encouraged to work at a sustainable pace. This means that teams work at a consistent pace that sustains a constant velocity that permits maintaining a high-quality standard. New agile teams tend be overly optimistic about what they can accomplish and sign up for too much work. After an iteration or two, they learn to sign up for just enough work so no overtime is needed to complete their tasks. A 40-hour week is the normal sustainable pace for XP teams; it is the amount of effort that, if put in week in and week out, allows people to accomplish the most work over the long haul while delivering good value.

团队可能需要不时地为不可持续的节奏而努力，但这应该是例外，而不是常态。如果需要短期加班，整个团队应该加班。如果是冲刺的最后一天并且有些故事没有测试，那么整个团队都应该熬夜完成测试，而不仅仅是测试人员。使用本书中推荐的实践和技术来学习如何规划测试和开发，并让测试“跟上”编码。在您的团队更好地管理其工作量和速度之前，预算额外的时间以帮助平衡步伐。

Teams might need to work for short bursts of unsustainable pace now and then, but it should be the exception, not the norm. If overtime is required for short periods, the whole team should be working extra hours. If it’s the last day of the sprint and some stories aren’t tested, the whole team should stay late to finish the testing, not just the testers. Use the practices and techniques recommended throughout this book to learn how to plan testing along with development and allow testing to “keep up” with coding. Until your team gets better at managing its workload and velocity, budget in extra time to help even out the pace.

在传统的软件开发中，开发团队与客户之间的关系更像是供应商关系。即使客户是内部客户，它也更像是两个独立的公司，而不是两个致力于创造商业价值的共同目标的团队。

In traditional software development, the relationship between the development teams and their customers is more like a vendor-supplier relationship. Even if the customer is internal, it can feel more like two separate companies than two teams working on a common goal of producing business value.

敏捷开发依赖于客户或至少是他们的代理人的密切参与。敏捷团队邀请客户进行协作，如果可能的话在同一地点工作，并密切参与开发过程。双方都了解彼此的长处和短处。

Agile development depends on close involvement from customers or, at the very least, their proxies. Agile teams have invited customers to collaborate, work in the same locations if possible, and be intimately involved with the development process. Both sides learn each other’s strengths and weaknesses.

这种关系的变化需要双方都认可，不管客户是内部客户还是外部客户。开放的关系对于敏捷项目的成功至关重要，在敏捷项目中，客户团队和开发团队之间的关系更像是一种伙伴关系，而不是供应商与供应商之间的关系。

This change in the relationships needs to be recognized by both sides, and it doesn’t matter whether the customer is internal or external. An open relationship is critical to the success of an agile project, where the relationship between the customer team and the development team is more like a partnership than a vendor-supplier relationship.

拥有一些有代表性的领域专家，同时让所有利益相关者不断了解情况，是开发人员与客户成功协作的一种方法。我们将在第五部分讨论其他内容。客户对于敏捷项目的成功至关重要。他们优先考虑将要构建的内容，并对产品质量拥有最终决定权。测试人员与客户密切合作，了解需求并定义验收测试，以证明满足条件。测试活动是开发团队与客户团队关系的关键。这就是测试专业知识对敏捷团队如此重要的原因。

Having a few representative domain experts, while keeping all stakeholders continually informed, is one approach to successful developer-customer collaboration. We’ll talk about others in Part V. Customers are critical to the success of your agile project. They prioritize what will be built and have the final say in the quality of the product. Testers work closely with customers to learn requirements and define acceptance tests that will prove that conditions of satisfaction are met. Testing activities are key to the development team-customer team relationship. That’s why testing expertise is so essential to agile teams.

组织的规模对项目的运行方式和公司结构的成熟度有很大的影响。组织越大，结构越趋于分层。随着自上而下的沟通渠道的发展，报告结构变得具有指导性，并且与技术和业务之间的协作不太兼容。

The size of an organization can have great impact on how projects are run and how the structure of a company matures. The larger the organization, the more hierarchical the structure tends to be. As top-down communication channels are developed, the reporting structures become directive and less compatible with collaboration between technology and business.

在敏捷项目中，重要的是每个开发团队都感到有权做出决策。如果您是一名经理，并且希望您的敏捷团队取得成功，请让他们自由地采取行动并做出创造性的反应。组织文化必须适应这种变化，敏捷项目才能成功。

In an agile project, it is important for each development team to feel empowered to make decisions. If you’re a manager and you want your agile teams to succeed, set them free to act and react creatively. The culture of an organization must adapt to this change for an agile project to be successful.

出于多种原因，测试人员坚持独立 QA 团队的概念，但主要原因是恐惧，具体来说：

Testers cling to the concept of an independent QA team for many reasons, but the main reason is fear, specifically:

我们经常听到 QA 经理提出诸如“我的公司正在实施敏捷开发”之类的问题。我的角色如何适应？” 这与“失去身份”的恐惧直接相关。

We often hear of QA managers asking questions such as, “My company is implementing agile development. How does my role fit in?” This is directly related to the “loss of identity” fears.

我们从经验中知道，新团队往往缺少可能对其成功至关重要的专家或专业知识。Lisa 的团队遇到了如此大的障碍，唯一能做的就是坐下来问：“我们的团队中缺少什么角色阻碍了我们？我们需要什么？另一个开发人员、另一个测试人员、数据库设计人员？” 我们都知道测试是一个广阔的领域。也许您需要在敏捷团队中有测试经验的人。或者您可能需要一名性能测试专家。花时间分析你的产品需要哪些角色才能成功，这一点很重要，如果你需要从团队外部填补这些角色，那就去做吧。

We know from experience that new teams are often missing specialists or expertise that might be key to their success. Lisa’s team has run into obstacles so large that the only thing to do was sit back and ask, “What role are we missing on our team that is holding us back? What do we need? Another developer, another tester, a database designer?” We all know that testing is a vast field. Maybe you need someone experienced in testing on an agile team. Or maybe you need a performance testing specialist. It’s critical that you take the time to analyze what roles your product needs to be successful, and if you need to fill them from outside the team, do it.

至关重要的是，产品团队中的每个人都了解自己的角色，或者弄清楚自己的角色是什么，因为他们现在是新敏捷团队的一员。这样做需要时间和培训。

It’s critical that everyone already on the product team understand their role or figure out what their role is now that they’re part of a new agile team. Doing this requires time and training.

我们在Agile 2007 的“会议中的会议”中主持了一次会议，询问人们在他们的敏捷团队中遇到了哪些与测试相关的问题。一位与会者告诉我们，他们按照敏捷文献所提倡的那样拆分了测试组织。但是，他们在没有任何培训的情况下将测试人员放入开发单元；三个月内，所有测试人员都辞职了，因为他们不了解自己的新角色。通过正确的培训和辅导，可以避免此类问题。

We hosted a session in the “Conference within a Conference” at Agile 2007 that asked people what testing-related problems they were having on their agile teams. One of the attendees told us that they split up their test organization as advocated by the agile literature. However, they put the testers into development units without any training; within three months, all of the testers had quit because they didn’t understand their new roles. Problems like these can be prevented with the right training and coaching.

当我们开始与我们的第一个敏捷团队合作时，没有太多资源可以帮助我们了解敏捷测试人员应该做什么或者我们应该如何与我们的团队一起工作。今天，你可以找到很多实践者，他们可以帮助训练测试人员适应敏捷环境，帮助测试团队进行敏捷转型。本地用户组、会议、研讨会、在线指导和邮件列表都为想要学习的测试人员和管理人员提供了宝贵的资源。在需要时不要害怕寻求帮助。良好的指导会给您带来良好的投资回报。

When we started working with our first agile teams, there weren’t many resources available to help us learn what agile testers should do or how we should work together with our teams. Today, you can find many practitioners who can help train testers to adapt to an agile environment and help test teams make the agile transition. Local user groups, conferences, seminars, online instruction, and mailing lists all provide valuable resources to testers and managers wanting to learn. Don’t be afraid to seek help when you need it. Good coaching gives a good return on your investment.

并非所有的敏捷团队都是一样的。敏捷开发有很多不同的方法，例如 XP、Scrum、Crystal、FDD、DSDM、OpenUP 和各种那些的混合。在我们看来，一些自称为“敏捷”的团队并没有真正实践敏捷。许多团队只是采用对他们有用的做法，而不管原始来源如何，或者他们发明了自己的做法。这很好，但如果他们不遵循任何敏捷核心价值观和原则，我们就会质疑给他们贴上敏捷标签。每月发布和免除文档并不等同于敏捷开发！

Not all agile teams are the same. There are lots of different approaches to agile development, such as XP, Scrum, Crystal, FDD, DSDM, OpenUP, and various mixes of those. Some self-titled “agile” teams are not, in our opinion, really practicing agile. Plenty of teams simply adopt practices that work for them regardless of the original source, or they invent their own. That’s fine, but if they don’t follow any of the core agile values and principles, we question giving them an agile label. Releasing every month and dispensing with documentation does not equate to agile development!

如果不同的团队成员对什么是“敏捷”、他们应该使用哪些实践或应该如何实践这些实践有相反的看法，就会有麻烦。例如，如果你是一名测试人员，正在推动团队实施持续集成，但程序员根本拒绝尝试，那么你就处于不利地位。如果您是一名未能成功参与某些实践的程序员，例如通过面向业务的测试来推动开发，那么您也会陷入冲突。

If different team members have opposing notions of what constitutes “agile,” which practices they should use, or how those practices are supposed to be practiced, there’s going to be trouble. For example, if you’re a tester who is pushing for the team to implement continuous integration, but the programmers simply refuse to try, you’re in a bad spot. If you’re a programmer who is unsuccessful at getting involved in some practices, such as driving development with business-facing tests, you’re also in for conflict.

团队必须就如何继续进行达成共识，以便成功过渡到敏捷。许多敏捷开发实践是协同的，因此如果单独使用它们，它们可能无法提供团队正在寻找的好处。也许团队可以同意对给定迭代次数的某些实践进行试验并评估结果。它可以决定寻求外部输入，以帮助他们了解这些做法以及它们如何组合在一起。不同的观点对团队有好处，但每个人都需要朝着同一个方向前进。

The team must reach consensus on how to proceed in order to make a successful transition to agile. Many of the agile development practices are synergistic, so if they are used in isolation, they might not provide the benefits that teams are looking for. Perhaps the team can agree to experiment with certain practices for a given number of iterations and evaluate the results. It could decide to seek external input to help them understand the practices and how they fit together. Diverse viewpoints are good for a team, but everyone needs to be headed in the same direction.

我们采访过的一些人描述了传统软件开发组织实施敏捷开发过程时经常出现的“迷你瀑布”现象。该组织用两周或四个星期的开发周期取代了六个月或一年的开发周期，并试图将所有传统的 SDLC 阶段压缩到这么短的时间内。自然地，他们继续遇到与以前相同的问题。图 3-1显示了迷你瀑布的“理想”版本，其中有一个代码和修复阶段，然后是测试——测试在编码完成之后但在下一次迭代开始之前进行。然而，真正发生的是测试被挤到迭代的末尾并且通常拖到下一个迭代中。程序员还没有太多需要解决的问题，所以他们开始着手下一次迭代。不久之后，一些团队的测试总是“落后”一个迭代，并且发布日期像往常一样被推迟。

Several people we’ve talked to described the “mini-waterfall” phenomenon that often occurs when a traditional software development organization implements an agile development process. The organization replaces a six-month or year-long development cycle with a two- or four-week one, and just tries to squeeze all of the traditional SDLC phases into that short period. Naturally, they keep having the same problems as they had before. Figure 3-1 shows an “ideal” version of the mini-waterfall where there is a code-and-fix phase and then testing—the testing comes after coding is completed but before the next iteration starts. However, what really happens is that testing gets squeezed into the end of the iteration and usually drags over into the next iteration. The programmers don’t have much to fix yet, so they start working on the next iteration. Before long, some teams are always an iteration “behind” with their testing, and release dates get postponed just as they always did.

图 3-1一个迷你瀑布流程

Figure 3-1 A mini-waterfall process

参与交付产品的每个人都需要时间和培训来理解敏捷背后的概念以及核心实践。经验丰富的教练可用于对团队的新实践进行实践培训，例如测试驱动开发。在较大的组织中，职能测试经理可以成为实践主管，并可以提供支持和资源，以便测试人员学习如何与他们的新团队进行沟通和协作。程序员和其他团队成员需要来自职能经理的类似帮助。强大的领导力将帮助团队找到从“迷你瀑布”迁移到真正的协作开发的方法，其中编码和测试集成到一个过程中。

Everyone involved with delivering the product needs time and training to understand the concepts behind agile as well as the core practices. Experienced coaches can be used to give hands-on training in practices new to the team, such as test-driven development. In larger organizations, functional test managers can become practice leads and can provide support and resources so that testers learn how to communicate and collaborate with their new teams. Programmers and other team members need similar help from their functional managers. Strong leadership will help teams find ways to migrate away from “mini-waterfall” to true collaborative development, where coding and testing are integrated into one process.

XP 开发了一个雷达图来帮助团队确定他们对关键 XP 实践的适应程度。他们测量了五种不同的关键实践：团队、编程、规划、客户和结对，并显示了团队对实践的适应程度。图 3-2显示了两个这样的图表。图表左图显示适配成功，而右图显示存在一些问题区域。

XP has developed a radar chart to help teams determine their level of adaptation to key XP practices. They measure five different key practices: team, programming, planning, customer, and pairing, and they show the level of adaptation to practices by teams. Figure 3-2 shows two such charts. The chart on the left shows successful adaptation, while the chart on the right shows that there are some problem areas.

图 3-2 XP 雷达图

Figure 3-2 XP Radar charts

很多人都经历过没有坚持下去的改变。一些开发组织经历了一系列“流行方法论”。他们举起手来想：“我们为什么要再做一次？” 人们陷入了旧的、不成功的模式。即使当他们尝试新事物时，他们也可能在压力下恢复旧习惯。以下只是一些人因过去的经验和他们对“事物的现状”的看法而拒绝改变的几个例子：

Lots of people have been through changes that didn’t stick. Some development organizations have lived through a succession of the “methodology du jour.” They throw up their hands and wonder, “Why should we do it again?” People get stuck in their old, unsuccessful patterns. Even when they try something new, they might revert to bad old habits when under stress. The following are just a few examples of people resisting change due to past experience and their perception of “the way things are”:

当面临向敏捷开发的过渡时，像这样的人往往不给新流程机会就离开。敏捷开发并不适合所有人，但培训和试验时间可以帮助调整态度。要求每个人都成为解决方案的一部分，并共同努力找出最适合他们特定情况的流程和实践。自组织团队可以成为一个强大的工具，可以用来让开发团队的所有成员确信他们可以控制自己的命运。

When faced with a transition to agile development, people like this often leave without giving the new process a chance. Agile development isn’t for everyone, but training and time to experiment can help adjust attitudes. Ask everyone to be part of the solution, and work together to find out what processes and practices work best for their particular situations. The self-organizing team can be a powerful tool to use to reassure all members of the development team that they’re in control of their own destiny.

每个新的敏捷团队成员都在从不同的角度进行转变。程序员通常习惯于编写产品代码并尽快发布。系统管理员和数据库专家可能习惯于在自己的孤岛中工作，按照自己的时间表执行请求。客户可能从未直接与开发团队成员交谈过。测试人员可能习惯于在项目结束时进来，根本不与程序员进行太多交互。

Each new agile team member is making the transition from a different perspective. Programmers are often used to writing production code and getting it released as quickly as possible. System administrators and database experts might be accustomed to working in their own silo, performing requests on their own schedule. Customers may never have talked directly with development team members. Testers might be used to coming in at the end of the project and not interacting much at all with programmers.

难怪向敏捷过渡会令人恐惧。团队可以制定规则和指南来帮助他们更好地沟通和合作。为了例如，Lisa 加入了一个新的敏捷团队，该团队的规则是如果有人要你与她结对，你必须同意。你可能无法在那一刻做对，但一旦你能解放自己，你就必须去帮助你的队友。

It’s no wonder a transition to agile can be scary. Teams can come up with rules and guidelines to help them communicate and work well together. For example, Lisa joined a new agile team whose rule was that if someone asked you to pair with her, you had to agree. You might not be able to do it right that minute, but as soon as you could free yourself up, you had to go help your teammate.

确定从事不同活动的人们需要什么，并找到提供这些需求的方法。客户需要某种方式来了解开发的进展情况以及是否满足他们的满意条件。开发人员需要了解业务优先级和要求。测试人员需要获取示例并将其转化为测试的方法。所有团队成员都希望感到自己是有价值的、一流的团队成员。每个团队成员还需要有安全感，可以自由地提出问题和尝试新想法。了解每个角色的观点有助于团队完成过渡。

Identify what people doing different activities need, and find ways to provide it. Customers need some way to know how development is progressing and whether their conditions of satisfaction are being met. Developers need to know business priorities and requirements. Testers need ways to capture examples and turn them into tests. All team members want to feel they are valued, first-class team members. Each team member also needs to feel safe and to feel free to raise issues and try new ideas. Understanding the viewpoint of each role helps teams through the transition.

当您开始迭代开发时，使用回顾为人们提供一个谈论他们恐惧的地方以及一个他们可以提供反馈的地方。让人们知道害怕是正常的。开放；教他们说他们害怕或不舒服是可以接受的。讨论每个恐惧的来源，从讨论中学习，做出决定，然后继续前进。恐惧是对变化的普遍反应。强迫人们做他们不想做的事情不利于积极的改变。以身作则。

When you start iterative development, use retrospectives to provide people with a place to talk about their fears and a place in which they can give feedback. Let people know that it’s normal to be fearful. Be open; teach them it is acceptable to say they are fearful or uncomfortable. Discuss each source of fear, learn from the discussion, make decisions, and move on. Fear is a common response to change. Forcing people to do something they don’t want is detrimental to positive change. Lead by example.

一个关键的成功因素是团队是否拥有所有权并有能力定制其方法。如果给予正确的帮助，人们可以改变他们的态度和看法。丽莎能够观察迈克·科恩 (Mike Cohn) 作为教练与她的团队一起工作。作为一个自组织团队，该团队必须找出并解决自己的问题。迈克确保他们有时间和资源来试验和改进。他确保企业了解质量比数量或速度更重要。每个团队，即使是自组织团队，都需要一位能够与组织的管理团队有效互动的领导者。

A critical success factor is whether the team takes ownership and has the ability to customize its approach. People can change their attitudes and their perceptions if they are given the right help. Lisa was able to observe Mike Cohn work with her team as a coach. As a self-organizing team, the team had to identify and solve its own problems. Mike made sure they had the time and resources to experiment and improve. He made sure that the business understood that quality was more important than quantity or speed. Every team, even a self-organizing team, needs a leader who can effectively interact with the organization’s management team.

实施变革需要时间并且可能令人沮丧，因此请务必庆祝您的团队取得的所有成功。当您在迭代的第四天达到为所有故事编写高级测试用例的目标时，请拍拍自己的背。当您刚刚交付了一个迭代的工作量时，召集团队一起玩问答游戏或共进午餐。如果你想让改变坚持下去，承认是很重要的。

Implementing change takes time and can be frustrating, so be sure to celebrate all successes your team achieves. Pat yourselves on the back when you meet your goal to write high-level test cases for all stories by the fourth day of the iteration. Get the team together for a trivia game or lunch when you’ve just delivered an iteration’s worth of work. Acknowledgment is important if you want a change to stick.

将测试人员集成到开发团队中，同时让他们继续向提供支持的 QA 经理报告是简化向敏捷开发过渡的一种方法。测试人员可以找到从与程序员的敌对关系转变为协作关系的方法。他们可以展示他们如何提供帮助团队了解客户的需求并提供适当的商业价值。他们可以举办愉快的活动来建立良好的团队互动。为队友准备饼干或巧克力是让他们走到你办公桌前的好方法！耐心和乐趣是很大的优势。

Integrating testers into development teams while letting them continue to report to a supportive QA manager is one way to ease the transition to agile development. Testers can find ways to move from an adversarial relationship with programmers to a collaborative one. They can show how they can help the team understand the customers’ needs and deliver appropriate business value. They can host enjoyable activities to build good team interactions. Having cookies or chocolate available for teammates is a good way to get them to walk over to your desk! Patience and a sense of fun are big advantages.

在敏捷项目中，期望会发生变化。在她以前的瀑布项目中，Janet 记得几周以来一直听到诸如“此功能已完成 90%”之类的评论。这些类型的指标在敏捷项目中毫无意义。没有签字来标记一个阶段的结束，并且项目的“完成”不是由门来衡量的。

In an agile project, expectations change. In her previous life in waterfall projects, Janet remembers hearing comments like “this feature is 90% done” for weeks. Those types of metrics are meaningless in agile projects. There are no sign-offs to mark the end of a phase, and the “doneness” of a project isn’t measured by gates.

有意义的指标由每个项目团队确定。在 Scrum 中，冲刺和发布燃尽图跟踪故事的完成情况，并可以为经理提供进度衡量标准，但不是用于向客户开账单的任何硬性“日期”。测试矩阵可用于跟踪功能测试覆盖率，但不提供签核文档。

Meaningful metrics are determined by each project team. In Scrum, sprint and release burndown charts track story completion and can give managers a measure of progress, but not any hard “dates” to use for billing customers. Test matrices can be used to track functionality test coverage but do not provide sign-off documentation.

一些经理难以理解的另一个变化是让团队做出自己的技术决策并管理自己的工作量。不再是经理决定什么是足够好的。团队（包括客户）定义了交付成功应用程序所需的质量水平。

The other change that is difficult for some managers to understand is letting the teams make their own technical decisions and manage their own workloads. It’s no longer the manager who decides what is good enough. It is the team (which includes the customer) that defines the level of quality necessary to deliver a successful application.

敏捷团队比传统团队估计和工作的时间更短。团队需要为良好的设计和执行计划足够的时间，而不是建立应急计划，以确保技术债务不会增加。敏捷团队的管理者不是在低层级管理团队的活动，而是专注于消除障碍，以便团队成员能够做到最好。

Agile teams estimate and work in smaller chunks of time than traditional teams. Rather than building in contingency, teams need to plan enough time for good design and execution in order to ensure that technical debt does not increase. Rather than managing the team’s activities at a low level, managers of agile teams focus on removing obstacles so that team members can do their best work.

业务利益相关者不喜欢惊喜。如果可以说服他们给团队足够的时间和资源来进行过渡，他们会发现敏捷开发可以让他们更准确地规划并以稳定的增量实现业务目标。

Business stakeholders don’t like surprises. If they can be convinced to give the team enough time and resources to make the transition, they’ll find that agile development lets them plan more accurately and achieve business goals in steady increments.

有时实际上是管理层决定开始进行敏捷开发。Lisa 公司的业务负责人选择尝试敏捷开发，以解决其软件危机。为了有效，他们需要有一套不同的管理期望。他们需要对做出重大改变的困难保持敏感，尤其是在一个运作不佳的组织中。

Sometimes it’s actually management that drives the decision to start doing agile development. The business leaders at Lisa’s company chose to try agile development in order to solve its software crisis. To be effective, they needed to have a different set of management expectations. They needed to be sensitive to the difficulty of making big changes, especially in an organization that wasn’t functioning well.

在所有情况下，在向高效敏捷团队过渡的漫长过程中，管理者都需要很大的耐心。他们的工作是确保他们提供必要的资源，并确保每个人都能学习如何完成高质量的工作。

In all cases, managers need lots of patience during what might be a long transition to a high-functioning agile team. It’s their job to make sure they provide the necessary resources and that they enable every individual to learn how to do high-quality work.

如果您是 QA 经理，请准备好帮助您的测试人员克服从定义的、顺序的测试阶段转移到他们在任何一天执行广泛不同任务的快节奏迭代时的挫败感。帮助他们适应这样的想法，即测试不再是开发之后发生的单独活动，而是测试和编码是集成的活动。

If you’re a QA manager, be prepared to help your testers overcome their frustrations with moving from defined, sequential testing stages to fast-paced iterations where they perform widely varied tasks on any given day. Help them adapt to the idea that testing is no longer a separate activity that occurs after development but that testing and coding are integrated activities.

如果您是一名测试人员或其他团队成员，在向敏捷开发过渡的过程中没有获得所需的支持，请考虑您的经理在理解敏捷开发方面可能遇到的困难。帮助他们了解您需要什么样的支持。

If you’re a tester or other team member who isn’t getting the support you need in your transition to agile development, think about the difficulties your managers might be having in understanding agile development. Help them to understand what kinds of support you need.

企业管理者最了解什么？这是底线——ROI （投资回报率）。要从您的管理层那里获得您需要的支持，请在他们可以理解的背景下构建您的需求。您团队的速度转化为新功能，使业务更有利可图。如果您需要时间和资金来学习和实施自动化测试工具，请向管理层解释随着时间的推移，自动化回归测试将使您的团队更快地进行并在每次迭代中提供更多功能。

What do business managers understand best? It’s the bottom line—the ROI (return on investment). To get the support you need from your management, frame your needs in a context that they can understand. Your team’s velocity translates into new features to make the business more profitable. If you need time and funds to learn and implement an automated test tool, explain to management that over time, automated regression tests will let your team go faster and deliver more functionality in each iteration.

与敏捷团队的所有成员一样，管理人员需要学习很多新概念并弄清楚他们如何适应团队成员。使用大的可见图表（或根据需要使用它们的虚拟等价物）以确保它们可以跟踪每次迭代和发布的进度。寻找最大化投资回报率的方法。通常，当存在可提供类似价值的更简单、更快速的解决方案时，企业会要求提供复杂且昂贵的功能。确保你解释了你的团队的工作如何影响底线。与他们合作，为利益相关者找到表达每个新功能需求的最佳方式。

Like all members of an agile team, managers need to learn a lot of new concepts and figure out how they fit as team members. Use big visible charts (or their virtual equivalents, as needed) to make sure they can follow the progress of each iteration and release. Look for ways to maximize ROI. Often, the business will ask for a complex and expensive feature when there is a simpler and quicker solution that delivers similar value. Make sure you explain how your team’s work affects the bottom line. Collaborate with them to find the best way for stakeholders to express the requirements for each new feature.

预算限制是大多数团队面临的现实。当资源有限时，您的团队需要更具创造力。整个团队的方法会有所帮助。也许，像 Lisa 的团队一样，您的团队购买软件的预算有限，所以您倾向于查看通常没有大量前期购买成本的开源测试自动化工具。与应用程序使用相同语言的工具不会帮助非编程测试人员，除非程序员与他们协作以自动化测试。利用团队的所有专业知识帮助您在业务限制范围内工作。

Budget limitations are a reality most teams face. When resources are limited, your team needs to be more creative. The whole-team approach helps. Perhaps, like Lisa’s team, your team has a limited budget to buy software, and so you tend to look at open-source test automation tools that usually don’t have a large up-front purchase cost. A tool that uses the same language as the application won’t help the non-programming testers unless the programmers collaborate with them to automate the tests. Leveraging all of the expertise on the team helps you work within the business limitations.

与您的团队遇到的所有挑战一样，尝试开发团队和管理层可以互相帮助以构建有价值的产品的新方法。同时，无论您采用何种开发方法，您可能都必须确保某些过程（如符合审计要求）得到必要的关注。

As with all challenges your team encounters, experiment with new ways that the development team and management can help each other to build a valuable product. At the same time, regardless of your development approach, you might have to make sure that some processes, such as conformance to audit requirements, receive the necessary attention.

TDD 等新技能很难。想方设法帮助您的团队腾出时间来掌握它们。在等待期间找到您可以独立进行的更改。例如，当程序员学习编写单元测试时，实现一个 GUI 测试工具，您只需很少的帮助即可使用。帮助团队迈出第一步。请记住，当人们恐慌时，他们会回到旧习惯，即使这些习惯不起作用。专注于微小的积极增量。

New skills such as TDD are hard. Find ways to help your team get time to master them. Find changes you can make independently while you wait. For example, while programmers learn to write unit tests, implement a GUI test tool that you can use with minimal help. Help the team make baby steps. Remember that when people panic, they go back to their old habits, even though those habits didn’t work. Focus on tiny positive increments.

有时你只需要看火车残骸。如果您的改进建议遭到拒绝，并且团队失败了，请再次提出您的建议并要求团队考虑尝试几次迭代。人们最愿意在他们感到最痛苦的地方做出改变。

Sometimes you just have to watch the train wreck. If your suggestions for improvement were rebuffed, and the team fails, bring your suggestion up again and ask the team to consider trying it for a few iterations. People are most willing to change in the areas where they feel the most pain.

您现在可能正在与以前没有与测试人员密切合作的程序员一起工作。向他们展示您可以提供哪些帮助。带着你发现的问题去找他们，而不是打开错误报告。请他们在签入之前与您一起检查代码。当他们意识到您贡献了真正的价值时，他们就更有可能倾听您的想法。

You might now be working with programmers who haven’t worked closely with testers before. Show them how you can help. Go to them with issues you’ve found rather than opening bug reports. Ask them to review code with you before they check it in. When they realize you’re contributing real value, they’re more likely to listen to your ideas.

阅读书籍和文章，参加用户组会议，学习新工具或脚本语言。开始学习您的应用程序的编码语言，并询问您团队中的程序员是否可以与他们结对或者他们是否会辅导您。您的同事会尊重您提高技能的愿望。如果您的本地用户组愿意听您关于敏捷测试的演讲，或者软件通讯发表了您的自动化文章，您的队友可能会注意到您也有一些值得一听的东西。

Read books and articles, go to user group meetings and conferences, and learn a new tool or scripting language. Start learning the language your application is coded in, and ask the programmers on your team if you can pair with them or if they’ll tutor you. Your coworkers will respect your desire to improve your skills. If your local user group is willing to listen to your presentation on agile testing, or a software newsletter publishes your automation article, your teammates might notice you have something worth hearing too.

成为合作者，而不是执行者。如果程序员不遵循编码标准，您可能会感到烦恼，但确保他们这样做不是您的工作。向团队提出您的问题并寻求他们的帮助。如果他们忽视了一个真正伤害团队的关键问题，你可能需要向你的教练或经理寻求帮助。但是要以“请帮我找到解决方案”的方式来做，而不是“让这些人表现得好”。如果您看到一个问题，其他人也很可能看到它。

Be a collaborator, not an enforcer. It might bug you if programmers don’t follow coding standards, but it’s not your job to make sure that they do so. Raise your issues with the team and ask for their help. If they ignore a critical problem that is really hurting the team, you might need to go to your coach or manager for help. But do that in a “please help me find a solution” vein rather than a “make these people behave” one. If you’re seeing a problem, chances are high that others see it too.

你一直很有耐心。你能想到的方法你都试过了，但是你的管理层不懂敏捷开发。程序员仍然会“翻墙”抛出有缺陷的、无法测试的代码，尽管你尽了最大努力，包括每天工作 14 小时，但这些代码仍按原样发布。没有人关心质量，尽管你尽了最大努力，你还是觉得自己被忽视了。也许是时候寻找一个更好的团队了。有些团队对他们现在的样子很满意，只是因为没有足够的痛苦而不想改变。丽莎所在的团队在混乱中茁壮成长，因为经常有机会找出服务器崩溃的原因并成为英雄。尽管使用敏捷实践成功完成了一个项目，但他们又回到了老习惯，Lisa 最终放弃了改变他们的尝试。

You’ve been patient. You’ve tried every approach you can think of, but your management doesn’t understand agile development. The programmers still throw buggy, untestable code “over the wall,” and that code is released as is despite your best efforts, including working 14-hour days. Nobody cares about quality, and you feel invisible despite your best efforts. It might be time to look for a better team. Some teams are happy the way they are and simply don’t feel enough pain to want to change. Lisa worked on a team that thrived on chaos, because there were frequent opportunities to figure out why the server crashed and be a hero. Despite a successful project using agile practices, they went back to their old habits, and Lisa finally gave up trying to change them.

许多组织，无论大小，都认为拥有一个独立的 QA 或测试团队很重要，这样才能获得关于产品质量的诚实意见。我们经常被问到这样的问题，“在整个团队方法中是否有测试组织的位置？” 和“如果是这样，它的作用是什么？”

Many organizations, both large and small, think it is important to have an independent QA or test team in order to get an honest opinion about the quality of a product. We’re often asked the questions, “Is there a place for a test organization in the whole-team approach?” and “If so, what is its role?”

我们希望将 QA 团队与开发团队分开的一些原因是：

Some of the reasons we’re given for wanting to keep the QA team separate from the development team are:

团队经常将“独立”与“独立”混淆。如果报告结构、预算和流程保持在独立的功能区域，则程序员和测试人员之间的划分是不可避免的。这会导致摩擦、竞争和“我们对他们”的态度。时间浪费在重复的会议上，程序员和测试人员没有共同的目标，并且不存在信息共享。

Teams often confuse “independent” with “separate.” If the reporting structure, budgets, and processes are kept in discrete functional areas, a division between the programmers and testers is inevitable. This can lead to friction, competition, and an “us versus them” attitude. Time is wasted on duplicate meetings, programmers and testers don’t share a common goal, and information sharing is nonexistent.

有一个 QA 经理和一个独立的测试团队是有原因的。但是，我们建议更改原因和结构。与其让测试人员作为一个独立的团队在编码后测试应用程序，不如将团队视为一个测试人员社区。提供一个学习型组织来帮助您的测试人员进行职业发展，并提供一个分享想法和互相帮助的地方。如果 QA 经理成为组织中的实践领导者，该人将能够教授测试人员所需的技能，使他们变得更强大，能够更好地应对不断变化的环境。

There are reasons for having a QA manager and an independent test team. However, we suggest changing the reasons as well as the structure. Rather than keeping the testers separate as an independent team to test the application after coding, think about the team as a community of testers. Provide a learning organization to help your testers with career development and a place to share ideas and help each other. If the QA manager becomes a practice leader in the organization, that person will be able to teach the skills that testers need to become stronger and better able to cope with the ever-changing environment.

我们不认为将测试人员与项目团队集成会妨碍测试人员做好他们的工作。事实上，敏捷团队的测试人员对他们作为客户倡导者的角色感觉非常强烈，也觉得他们可以影响团队的其他成员进行质量思考。

We don’t believe that integrating the testers with the project teams prevents testers from doing their jobs well. In fact, testers on agile teams feel very strongly about their role as customer advocate and also feel they can influence the rest of the team in quality thinking.

敏捷开发中的全团队方法已经促使许多采用敏捷开发的组织解散了他们独立的 QA 团队，并将他们的测试人员派往项目组工作。虽然这听起来不错，但一些组织发现它并没有按预期工作。当发现自己在一个敏捷开发团队中不知道自己应该做什么时，不止一个组织的大部分（如果不是全部）测试人员都辞职了。

The whole-team approach in agile development has provoked many organizations that have adopted agile development to disband their independent QA teams and send their testers to work with the project groups. While this sounds great, some organizations have found that it doesn’t work as expected. More than one organization has had most, if not all, of their testers quit when they found themselves on an agile development team with no idea what they should be doing.

开发人员接受结对编程、测试驱动开发和其他敏捷实践方面的培训，而测试人员通常似乎根本没有接受任何培训。许多组织未能认识到测试人员还需要接受结对测试、处理不完整和不断变化的需求、自动化以及所有其他所需的新技能方面的培训。测试人员接受培训和指导非常重要，这样他们可以获得有助于他们成功的技能和理解，例如如何与客户合作编写面向业务的测试。程序员可能还需要指导以了解面向业务的测试的重要性以及整个团队编写和自动化测试的方法。

Developers get training on pair programming, test-driven development, and other agile practices, while testers often seem to get no training at all. Many organizations fail to recognize that testers also need training on pair testing, working with incomplete and changing requirements, automation, and all of the other new skills that are required. It’s critical that testers receive training and coaching so that they can acquire the skills and understanding that will help them succeed, such as how to work with customers to write business-facing tests. Programmers also might need coaching to understand the importance of business-facing tests and the whole-team approach to writing and automating tests.

Janet 帮助将几个独立的测试团队集成到敏捷项目中。她发现大多数测试人员可能需要长达六个月的时间才能开始对使用新流程充满信心。

Janet has helped integrate several independent test teams into agile projects. She finds that it can take up to six months for most testers to start feeling confident about working with the new process.

程序员和测试人员的配对只能改善关于产品质量的沟通。如果无法在开发环境中重现该行为，开发人员通常需要在测试人员的工作站上观察应用程序的行为。测试人员有时可以与开发人员坐下来重现问题，这比他们尝试记录缺陷中的步骤更容易、更快速。这种互动减少了花在非口头交流上的时间。

The pairing of programmers and testers can only improve communication about the quality of the product. Developers often need to observe the behavior of the application on the tester’s workstation if that behavior can’t be reproduced in the development environment. Testers can sometimes sit down with the developer to reproduce a problem more easily and quickly than they can by trying to record the steps in a defect. This interaction reduces the time spent on non-oral communication.

我们从测试人员那里听到的关于此主题的评论包括以下内容：

Comments we’ve heard from testers on this subject include the following:

集成项目团队的一大优势是只有一个预算和一个时间表。如果所有功能都没有完成，就没有“测试”时间可以缩短。如果没有时间测试新功能，那么一开始就没有时间开发它。正如我们在整本书中指出的那样，整个团队对质量负责的方法非常强大。

One major advantage of an integrated project team is that there’s only one budget and one schedule. There is no “testing” time to cut if all of the functionality is not finished. If there is no time to test a new feature, then there is no time to develop it in the first place. The whole-team approach to taking responsibility for quality is very powerful, as we point out throughout this book.

测试人员需要是开发团队的正式成员，测试任务需要与其他任务一样受到重视。同样，整个团队的测试方法对确保在每次迭代和发布结束时完成测试任务大有帮助。一定要使用回顾来评估测试人员需要与他们的新敏捷团队集成的内容以及他们可能需要获得的技能。例如，测试人员可能需要来自程序员或特定类型测试专家的更多支持。

Testers need to be full-fledged members of the development team, and testing tasks need to be given the same attention as other tasks. Again, the whole-team approach to testing goes a long way toward ensuring that testing tasks are completed by the end of each iteration and release. Be sure to use retrospectives to evaluate what testers need to integrate with their new agile team and what skills they might need to acquire. For example, testers might need more support from programmers, or from someone who’s an expert in a particular type of testing.

为敏捷开发规划组织变革的明智方法对成功转型至关重要。让 QA 和开发经理弄清楚他们自己在新的敏捷组织中的角色。让他们计划如何帮助他们的测试人员和开发人员在新的敏捷团队中提高工作效率。提供团队不知道的敏捷实践培训。确保所有团队都可以相互沟通。提供一个框架，让每个团队边走边学，团队将找到成功的方法。

A smart approach to planning the organizational changes for agile development makes all the difference to a successful transition. Ask the QA and development managers to figure out their own roles in the new agile organization. Let them plan how they will help their testers and developers be productive on the new agile teams. Provide training in agile practices that the team doesn’t know. Make sure all of the teams can communicate with each other. Provide a framework that lets each team learn as it goes, and the teams will find a way to succeed.

敏捷项目团队通常被认为是跨职能的，因为每个团队都有来自许多不同背景的成员。传统的跨职能团队和敏捷团队之间的区别在于整个团队努力的方法。只要项目或永久团队存在，成员就不仅仅是“代表”他们在团队中的职能，而是成为团队的真正成员（见图4-1）。

Agile project teams are generally considered cross-functional, because each team has members from many different backgrounds. The difference between a traditional cross-functional team and an agile team is the approach to the whole-team effort. Members are not just “representing” their functions in the team but are becoming true members of the team for as long as the project or permanent team exists (see Figure 4-1).

图 4-1传统职能团队结构与敏捷团队结构

Figure 4-1 Traditional functional teams structure vs. agile team structure

由于项目规模不同，项目团队的结构也可能不同。拥有大型项目或许多同时发生的项目的组织正在使用矩阵型结构取得成功。来自不同职能领域的人联合起来组成一个虚拟团队，同时仍然向各自的组织结构汇报。在大型组织中，一群测试人员可能会从一个项目转移到另一个项目。一些专家，例如安全或性能测试人员，可能会在多个团队之间共享。如果您正在启动一个项目，请确定该项目将需要的所有资源。在开始之前确定所需的测试人员数量和所需的技能组合。测试人员从团队开始，一直工作到项目完成，然后再继续下一个项目。

Because projects vary in size, project teams might vary in structure. Organizations with large projects or many projects that happen simultaneously are having success using a matrix-type structure. People from different functional areas combine to form a virtual team while still reporting back to their individual organizational structures. In a large organization, a pool of testers might move from project to project. Some specialists, such as security or performance testers, might be shared among several teams. If you’re starting up a project, identify all of the resources the project will need. Determine the number of testers required and the skill set needed before you start. The testers start with the team and keep working until the project is complete, and at that time they go on to the next project.

虽然测试人员是团队的一部分，但他们的日常工作与项目团队的其他工作一样受到管理。测试人员可以从更大的测试人员社区中汲取新想法，其中包括大型组织中不同项目团队的测试人员。所有测试人员都可以共享知识和想法。在实施绩效审查的组织中，QA 经理（如果有的话）可能会推动审查并从项目团队那里获得输入。

While testers are part of the team, their day-to-day work is managed the same as the rest of the project team’s work. A tester can bounce new ideas off of the larger tester community, which includes testers on different project teams across a large organization. All testers can share knowledge and ideas. In organizations that practice performance reviews, the QA manager (if there is one) might drive the reviews and get input from the project team.

与任何新团队一样，团队凝聚起来需要一段时间。如果项目的长度很短并且团队不断变化，组织需要意识到每个项目的第一次或两次迭代将包括新团队成员习惯彼此合作。根据需要重构您的组织，并记住将您的客户包括在内。最好的团队是那些学会一起工作并且彼此建立信任的团队。

As with any new team, it takes a while for a team to jell. If the length of the project is short and the teams are constantly changing, the organization needs to be aware that the first iteration or two of every project will include the new team members getting used to working with each other. Refactor your organization as needed, and remember to include your customers. The best teams are those that have learned to work together and have developed trust with one another.

关于测试人员数量与开发人员数量的“正确”比例，已经有很多讨论。组织已使用此比率来确定项目需要多少测试人员，以便他们可以相应地雇用。与传统项目一样，没有“正确”的比例，每个项目都需要单独评估。所需测试人员的数量会有所不同，具体取决于应用程序的复杂性、测试人员的技能组合以及所使用的工具。

There have been many discussions about the “right” ratio of the number of testers to the number of developers. This ratio has been used by organizations to determine how many testers are needed for a project so that they can hire accordingly. As with traditional projects, there is no “right” ratio, and each project needs to be evaluated on its own. The number of testers needed will vary and depends upon the complexity of the application, the skill set of the testers, and the tools used.

我们曾在测试人员与开发人员比例为 1:20 到 1:1 的团队中工作。这是我们的一些经验。

We have worked on teams with a tester-developer ratio of anywhere from 1:20 to 1:1. Here are a couple of our experiences.

团队不应关注比率，而应评估他们需要的测试技能并找到合适的资源。负责测试的团队可以不断评估自己是否具备所需的专业知识和带宽。使用回顾来确定是否存在雇佣更多测试人员可以解决的问题。

Rather than focus on a ratio, teams should evaluate the testing skills they need and find the appropriate resources. A team that takes responsibility for testing can continually evaluate whether it has the expertise and bandwidth it needs. Use retrospectives to identify whether there’s a problem that hiring more testers would solve.

正如我们在第 2 章“敏捷测试人员的十项原则”中所讨论的，有一些品质可以使测试人员适合在敏捷团队中工作。我们不想详细说明要聘请什么样的测试人员，因为每个团队的需求都不同。但是，我们确实认为态度是一个重要因素。这是一个关于 Lisa 的团队如何努力聘请新的敏捷测试人员的故事。

As we discussed in Chapter 2, “Ten Principles for Agile Testers,” there are certain qualities that make a tester suited to working on an agile team. We don’t want to go into a lot of detail about what kind of tester to hire, because every team’s need is different. However, we do believe that attitude is an important factor. Here’s a story of how Lisa’s team struggled to hire a new agile tester.

我们需要考虑的不仅仅是测试人员和程序员在团队中扮演的角色。无论您想担任什么角色，最重要的考虑因素是该人如何融入您的团队。使用敏捷的全团队方法，团队中的专家可能会被要求走出他们的专业领域并参与其他活动。每个团队成员都需要高度关注质量和交付业务价值。在扩大团队时，考虑的不仅仅是技术技能。

We need to consider more than just the roles that testers and programmers perform on the team. No matter what role you’re trying to fill, the most important consideration is how that person will fit on your team. With the agile whole-team approach, specialists on the team might be asked to step outside their areas of expertise and pitch in on other activities. Each team member needs to have a strong focus on quality and delivering business value. Consider more than just technical skills when you’re expanding your team.

根据我们的经验，当团队能够识别和解决他们自己的问题时，他们会取得最好的进展。如果您是一名经理，请抵制将您所有的好想法强加给团队的诱惑。有些问题，比如人事问题，最好由管理者来解决，而在需要领导的时候，也有教练需要大力鼓励和带领球队的时候。一个新的敏捷团队需要时间来学习如何确定问题的优先级和解决问题，但团队犯错误和跌跌撞撞几次也没关系。我们认为一个高效的团队必须自我成长。如果您是一名测试人员，您可以很好地帮助团队找出获得快速反馈的方法，使用回顾等实践来确定问题的优先级并解决问题，并找到帮助您的团队开发出更好软件的技术。

In our experience, teams make the best progress when they’re empowered to identify and solve their own problems. If you’re a manager, resist the temptation to impose all your good ideas on the team. There are problems, such as personnel issues, that are best solved by managers, and there are times a coach needs to provide strong encouragement and lead the team when it needs leadership. It takes time for a new agile team to learn how to prioritize and solve its problems, but it’s okay for the team to make mistakes and stumble a few times. We think a high-functioning team has to grow itself. If you’re a tester, you’re in a good position to help the team figure out ways to get fast feedback, use practices such as retrospectives to prioritize and address issues, and find the techniques that help your team produce better software.

您可能需要让其他团队参与进来，以帮助您的团队取得成功。安排会议；找到尽可能多的沟通方式。使用 Scrum of Scrums 来保持多个团队的协调，或者只是让其他团队参与进来。如果您必须聘请专家来帮助进行安全测试，请与该专家结对并尽可能多地学习，并帮助他们了解您的项目。

You might need to get other teams on board to help your team succeed. Set up meetings; find ways to communicate as much as possible. Use a Scrum of Scrums to keep multiple teams coordinated, or just get involved with the other teams. If you have to bring in an expert to help with security testing, pair with that expert and learn as much as you can, and help them learn about your project.

如果团队分散在不同的地点和时区，想办法尽可能多地进行直接沟通。也许代表来自每个团队可以每周调整一到两次他们的时间，这样他们就可以每周召开一次电话会议。尽可能打电话而不是发送电子邮件。Lisa 的团队调整了其计划会议时间，以包括一名在深夜工作的远程团队成员。他们将会议安排在他的一天与团队一天的其余时间重叠的时间。

If teams are scattered in different locations and time zones, figure out how to get as much direct communication as possible. Maybe representatives from each team can adjust their hours once or twice a week so that they can teleconference once a week. Make a phone call instead of sending an email whenever possible. Lisa’s team adjusted its planning meeting times to include a remote team member who works late at night. They schedule meetings for a time where his day overlaps with the rest of the team’s day.

每个团队成员对团队都具有同等的价值。如果测试人员或任何其他团队成员感到被冷落或被低估，则整个团队的方法注定要失败。确保邀请测试人员参加所有会议。如果您是一名测试员，而有人忘记邀请您参加会议，请自己邀请。非技术测试人员可能认为他们会在设计会议上格格不入或不知所措，但有时他们会提出技术人员没有想到的好问题。

Every team member has equal value to the team. If testers or any other team members feel left out or less valued, the whole-team approach is doomed. Make sure testers are invited to all meetings. If you’re a tester and someone forgets to invite you to a meeting, invite yourself. Nontechnical testers might think they’ll be out of place or overwhelmed at a design meeting, but sometimes they ask good questions that the techies didn’t think of.

测试人员有权寻求和获得帮助。如果您是一名被自动化问题困住的测试人员，请鼓起勇气向团队成员寻求帮助。该人现在可能很忙，但他或她必须承诺在合理的时间内为您提供帮助。如果您是团队的经理或领导者，请确保这种情况正在发生，如果没有发生，请向团队提出问题。

Testers have a right to ask for and get help. If you’re a tester stuck on an automation problem, have the courage to ask a team member for help. That person might be busy right now, but he or she must commit to helping you in a reasonable amount of time. If you’re a manager or leader on your team, make sure this is happening, and raise the issue to the team if it’s not.

以个人为基础衡量和评估绩效可能会破坏团队协作。我们不希望程序员觉得她不应该承担测试任务，因为她被评为交付生产代码。我们不希望系统管理员忙于确保实现她的个人目标，以致于无法帮助解决测试环境问题。

Measuring and rating performance on an individual basis risks undermining team collaboration. We don’t want a programmer to feel she shouldn’t take on a testing task because she’s rated on delivering production code. We don’t want a system administrator to be so busy making sure her individual goals are met that she can’t help with a test environment problem.

相反，一个试图与团队良好合作的优秀执行者不应该因为团队的其他成员没有齐心协力而被淘汰。这是经理需要挺身而出帮助团队找到方向的时候。如果主要错误进入生产，没有人应该责怪测试人员。相反，整个团队应该分析发生的事情并开始采取措施防止再次发生。

Conversely, a good performer who was trying to work well with the team shouldn’t be knocked because the rest of the team didn’t pull together. This is a time when a manager needs to step up and help the team find its way. If major bugs made it to production, nobody should blame the testers. Instead, the whole team should analyze what happened and start taking steps to prevent a recurrence.

开发团队需要牢记业务需求。设定服务于业务的目标，提高盈利能力，让客户更快乐。与企业密切合作，让您的成功帮助整个公司取得成功。

The development team needs to keep the business needs in mind. Set goals that serve the business, increase profitability, and make the customers happier. Work closely with the business so that your successes help the whole company succeed.

正如我们在第 3 章“文化挑战”中提到的，庆祝每一次成功，无论多么小。庆祝活动可能是击掌、公司提供的午餐，或者可能只是提前下班参加一些社交活动。Lisa 团队的 ScrumMaster 在站立会议上为特殊成就颁发金星。感谢帮助您和您的团队的人。

As we mentioned in Chapter 3, “Cultural Challenges,” celebrate every success, however small. A celebration might be a high-five, a company-provided lunch, or maybe just leaving work early to socialize a bit. The ScrumMaster on Lisa’s team hands out gold stars at stand-up meetings for special accomplishments. Acknowledge the people who help you and your team.

团队可以找到新颖的方式来认可彼此的贡献。开发团队和客户团队都出席的迭代审查和演示会议是认可个人和团队成就的良好场所。

Teams can find novel ways to recognize each other’s contributions. Iteration review and demonstration meetings, where both the development team and customer team are present, are a good setting for recognizing both individual and team achievements.

如果您是敏捷团队的新测试人员，尤其是新的敏捷团队，您可以做些什么来帮助团队克服组织挑战并取得成功？您如何融入团队并贡献您的特殊技能和经验？

If you’re a new tester on an agile team, especially a new agile team, what can you do to help the team overcome organizational challenges and succeed? How can you fit in with the team and contribute your particular skills and experience?

将我们在第 2 章中描述的十项原则付诸实践。勇气尤为重要。起身去与人交谈；询问你能提供什么帮助。通过直接沟通联系团队成员和其他团队。注意障碍并要求团队帮助移除它们。

Put the ten principles we described in Chapter 2 to work. Courage is especially important. Get up and go talk to people; ask how you can help. Reach out to team members and other teams with direct communication. Notice impediments and ask the team to help remove them.

敏捷开发之所以有效，是因为它消除了我们前进道路上的障碍，让我们做到最好。无论是个人还是团队，我们都可以感到自豪和满足。当我们遵循敏捷原则时，我们可以很好地协作，使用反馈来帮助改进我们的工作方式，并始终寻找新的更好的方法来实现我们的目标。所有这些意味着我们可以不断提高产品质量。

Agile development works because it gets obstacles out of our path and lets us do our best work. We can feel proud and satisfied, individually and as a team. When we follow agile principles, we collaborate well, use feedback to help improve how we work, and always look for new and better ways to accomplish our goals. All this means we can continually improve the quality of our product.

精益软件开发从业者寻找减少测量数量的方法，并找到将驱动正确行为的测量。实施精益软件开发：从概念到现金，作者 Mary 和 Tom Poppendieck，是一个很好的资源，可以教授如何将精益计划应用于您的测试和开发工作。

Lean software development practitioners look for ways to reduce the number of measurements and find measurements that will drive the right behaviors. Implementing Lean Software Development: From Concept to Cash, by Mary and Tom Poppendieck, is an excellent resource that teaches how to apply lean initiatives to your testing and development efforts.

根据 Poppendiecks [2007] 的说法，一个基本的精益衡量标准是“从概念到现金”，从客户的功能请求到交付软件所花费的时间。他们称这种测量为“周期时间”。重点在于团队“反复且可靠地”交付新业务价值的能力。然后团队尝试不断改进他们的流程并减少周期时间。

According to the Poppendiecks [2007], a fundamental lean measurement is the time it takes to go “from concept to cash,” from a customer’s feature request to delivered software. They call this measurement “cycle time.” The focus is on the team’s ability to “repeatedly and reliably” deliver new business value. Then the team tries to continuously improve their process and reduce the cycle time.

涉及整个团队的周期时间等度量比仅限于孤立角色或团体。修复缺陷通常需要多长时间？团队可以做些什么来减少延迟，减少所花费的时间？这些类型的指标鼓励协作以进行改进。

Measurements such as cycle time that involve the whole team are more likely to drive you toward success than are measures confined to isolated roles or groups. How long does it usually take to fix a defect? What can the team do to reduce that latency, the amount of time it takes? These types of metrics encourage collaboration in order to make improvements.

Poppendiecks 在他们的书中解释的另一个精益衡量标准是财务回报。如果团队正在开发一种有利可图的产品，则需要了解如何才能实现最大利润。即使团队正在开发主要目标不是利润的内部软件或其他产品，它仍然需要查看 ROI 以确保它提供最佳价值。确定业务目标并找到衡量团队交付成果的方法。公司是否正在努力吸引新客户？跟踪新功能发布时有多少新帐户登录。

Another lean measurement the Poppendiecks explain in their book is financial return. If the team is developing a profitable product, it needs to understand how it can work to achieve the most profit. Even if the team is developing internal software or some other product whose main goal isn’t profit, it still needs to look at ROI to make sure it is delivering the best value. Identify the business goals and find ways to measure what the team delivers. Is the company trying to attract new customers? Keep track of how many new accounts sign on as new features are released.

精益开发寻找取悦客户的方法，这应该是所有软件开发的目标。Poppendiecks 举例说明了衡量客户是否满意的简单方法。

Lean development looks for ways to delight customers, which ought to be the goal for all software development. The Poppendiecks give examples of simple ways you can measure whether your customers are delighted.

我们喜欢精益指标，因为它们与我们提供商业价值的目标一致。为什么我们对指标感兴趣？我们将在下一节中进行介绍。

We like the lean metrics, because they’re congruent with our goal to deliver business value. Why are we interested in metrics at all? We’ll go into that in the next section.

收集和跟踪指标是有充分理由的。也有一些非常糟糕的。任何人都可能以糟糕的方式使用好的指标，例如将它们用作单个团队成员绩效评估的基础。然而，没有指标，你如何衡量你的进步？

There are good reasons to collect and track metrics. There are some really bad ones too. Anyone can use good metrics in terrible ways, such as using them as the basis for an individual team member’s performance evaluation. However, without metrics, how do you measure your progress?

当指标被用作路标时——告诉团队何时偏离轨道或提供反馈表明它在正确的轨道上——它们值得收集。我们的单元测试数量每天都在增加吗？为什么代码覆盖率从 75% 下降到 65%？这可能是一个很好的理由——也许我们摆脱了测试覆盖的未使用代码。指标可以提醒我们注意问题，但孤立地看，它们通常不会提供价值。

When metrics are used as guideposts—telling the team when it’s getting off track or providing feedback that it’s on the right track—they’re worth gathering. Is our number of unit tests going up every day? Why did the code coverage take a dive from 75% to 65%? It might have been a good reason—maybe we got rid of unused code that was covered by tests. Metrics can alert us to problems, but in isolation they don’t usually provide value.

衡量实现团队目标的旅程中的里程碑的指标很有用。如果我们的目标是将单元测试代码覆盖率提高 3%，我们可能会在每次签入时运行代码覆盖率，以确保我们没有懈怠单元测试。如果我们没有达到预期的改进，找出原因比抱怨我们的奖金因此减少了多少更重要。我们不应专注于个别测量，而应专注于目标和实现该目标的趋势。

Metrics that measure milestones along a journey to achieve team goals are useful. If our goal is to increase unit test code coverage by 3%, we might run the code coverage every time we check in to make sure we didn’t slack on unit tests. If we don’t achieve the desired improvement, it’s more important to figure out why than to lament whatever amount our bonus was reduced as a result. Rather than focus on individual measurements, we should focus on the goal and the trending toward reaching that goal.

指标帮助团队（包括客户）跟踪迭代和发布或史诗中的进度。如果我们正在使用燃尽图，并且我们正在燃烧而不是燃烧，这是停止的危险信号，看看发生了什么，并确保我们理解并解决问题。也许团队缺少有关故事的重要信息。指标（包括燃尽图）不应用作惩罚形式或责备来源。例如，诸如“为什么您的估计值太低？”之类的问题。或者“为什么你不能完成所有的故事？” 最好来自团队并表述为“为什么我们的估计如此低？” 和“为什么我们没有完成我们的故事？”

Metrics help the team, customers included, to track progress within the iteration and within the release or epic. If we’re using a burndown chart, and we’re burning up instead of down, that’s a red flag to stop, take a look at what’s happening, and make sure we understand and address the problems. Maybe the team lacked important information about a story. Metrics, including burndown charts, shouldn’t be used as a form of punishment or source of blame. For example, questions like “Why were your estimates too low?” or “Why can’t you finish all of the stories?” would be better coming from the team and phrased as “Why were our estimates so low?” and “Why didn’t we get our stories finished?”

如果使用得当，指标可以激励团队。Lisa 的团队跟踪每个构建中运行的单元测试的数量。重大里程碑——100 次测试、1000 次测试、3000 次测试——值得庆祝。每天增加那么多的单元测试是对开发和客户团队的一个很好的反馈。然而，重要的是要认识到数字本身没有任何意义。例如，测试可能写得不好，或者要有一个经过良好测试的产品，我们可能需要 10,000 个测试。数字不能孤立地发挥作用。

Metrics, used properly, can be motivating for a team. Lisa’s team tracks the number of unit tests run in each build. Big milestones—100 tests, 1000 tests, 3000 tests—are a reason to celebrate. Having that number of unit tests go up every day is a nice bit of feedback for the development and customer teams. However, it is important to recognize that the number itself means nothing. For example, the tests might be poorly written, or to have a well tested product, maybe we need 10,000 tests. Numbers don’t work in isolation.

当您试图弄清楚要衡量什么时，首先要了解您要解决的问题是什么。当你知道问题陈述时，你可以设定一个目标。这些目标需要是可衡量的。“将 XYZ 应用程序的平均响应时间减少到 20 个并发用户的 1.5 秒”比“提高 XYZ 应用程序性能”效果更好。如果您的目标是可衡量的，那么您需要收集的衡量指标来跟踪指标将是显而易见的。

When you’re trying to figure out what to measure, first understand what problem you are trying to solve. When you know the problem statement, you can set a goal. These goals need to be measurable. “Reduce average response time on the XYZ application to 1.5 seconds with 20 concurrent users” works better than “Improve the XYZ application performance.” If your goals are measurable, the measurements you need to gather to track the metrics will be obvious.

请记住将指标用作激励力量，而不是用来打击团队的士气。这个智慧值得重复：关注目标，而不是指标。也许您没有使用正确的指标来衡量您是否实现了团队的目标，或者您可能没有在上下文中解释它们。缺陷报告数量的增加可能意味着团队在测试方面做得更好，而不是他们编写了更多有缺陷的代码。如果你的指标无法帮助您了解实现目标的进度，您可能有错误的指标。

Remember to use metrics as a motivating force and not for beating down a team’s morale. This wisdom bears repeating: Focus on the goal, not the metrics. Maybe you’re not using the right metrics to measure whether you’re achieving your team’s objectives, or perhaps you’re not interpreting them in context. An increased number of defect reports might mean the team is doing a better job of testing, not that they are writing more buggy code. If your metrics aren’t helping you to understand your progress toward your goal, you might have the wrong metrics.

马克吐温推广了他归功于本杰明迪斯雷利的一句话：“谎言分三种：谎言、该死的谎言和统计数据。” 可衡量的目标是一件好事；如果你不能以某种方式衡量它们，你就无法判断你是否实现了它们。另一方面，使用指标来判断个人或团队的表现是危险的。统计数据本身可以被扭曲成任何解释并以有害的方式使用。

Mark Twain popularized the saying, which he attributed to Benjamin Disraeli, “There are three kinds of lies: lies, damned lies, and statistics.” Measurable goals are a good thing; if you can’t gauge them in some way, you can’t tell if you achieved them. On the other hand, using metrics to judge individual or team performance is dangerous. Statistics by themselves can be twisted into any interpretation and used in detrimental ways.

以代码行为例，这是一种传统的软件量尺。更多的代码行是好事，意味着团队一直在生产，还是坏事，意味着团队正在编写低效的意大利面条式代码？

Take lines of code, a traditional software measuring stick. Are more lines of code a good thing, meaning the team has been productive, or a bad thing, meaning the team is writing inefficient spaghetti-style code?

发现的缺陷数量如何？根据测试人员发现的缺陷数量来判断测试人员是否有意义？这如何帮助他们更好地完成工作？可以肯定地说，每行代码产生更多缺陷的开发团队做得不好吗？或者发现更多缺陷的团队做得很好？即使这个想法站得住脚，一个团队被数字打得头破血流又有多大的动力？这会让团队成员开始编写无缺陷的代码吗？

What about number of defects found? Does it make any sense to judge testers by the number of defects they found? How does that help them do their jobs better? Is it safe to say that a development team that produces a higher number of defects per lines of code is doing a bad job? Or that a team that finds more defects is doing a good job? Even if that thought holds up, how motivating is it for a team to be whacked over the head with numbers? Will that make the team members start writing defect-free code?

我们知道，无论我们衡量什么，都必然会发生变化。有多少测试正在运行并通过？距离我们需要“现成的构建”还有多少天？完整构建是否通过？我们看不到和容易解释的指标不值得拥有。如果您想跟踪通过测试的数量，请确保该指标以正确的方式对正确的人可见。可见的大图表是我们所知的显示指标的最有效方式。

We know that whatever we measure is bound to change. How many tests are running and passing? How many days until we need a “build on the shelf”? Is the full build passing? Metrics we can’t see and easily interpret aren’t worth having. If you want to track the number of passing tests, make sure that metric is visible in the right way, to the right people. Big visible charts are the most effective way of displaying metrics we know.

表 5-1开始和结束指标

Table 5-1 Starting and Ending Metrics

表 5-2每日构建结果

Table 5-2 Daily Build Results

你的指标值得麻烦吗？不要为了产生数字而测量。想想你将从这些数字中学到什么。在下一节中，我们将考虑您可以从指标中获得的投资回报。

Are your metrics worth the trouble? Don’t measure for the sake of producing numbers. Think about what you’ll learn from those numbers. In the next section, we consider the return on investment you can expect from metrics.

当您确定所需的指标时，请确保您可以以合理的成本获得它们。如果您的持续构建提供了有用的数字，那么它会带来很好的价值。无论如何，您都在运行构建，如果它给我们提供了额外的信息，那就太好了。如果你需要做很多额外的工作来获取信息，问问自己这是否值得。

When you identify the metrics you need, make sure you can obtain them at a reasonable cost. If your continual build delivers useful numbers, it delivers good value. You’re running the build anyway, and if it gives us extra information, that’s gravy. If you need a lot of extra work to get information, ask yourself if it’s worth the trouble.

Lisa 的团队在跟踪每个故事实际花费的时间与估计时间方面遇到了很多麻烦。除了显而易见的事实，他们还学到了什么那估计只是这样吗？不多。一些有经验的团队发现他们可以省去冲刺燃尽图，因为任务板给了他们足够的信息来衡量他们的进度。他们可以将花费的时间用于估计任务并计算剩余时间以进行更有成效的活动。

Lisa’s team went to a fair amount of trouble to track actual time spent per story versus estimated time. What did they learn other than the obvious fact that estimates are just that? Not much. Some experienced teams find they can dispense with the sprint burndown chart because the task board gives them enough information to gauge their progress. They can use the time spent estimating tasks and calculating the remaining hours on more productive activities.

这并不意味着我们建议您停止跟踪这些测量值。新团队需要了解他们的速度和燃尽率，这样他们才能稳步提高。

This doesn’t mean we recommend that you stop tracking these measurements. New teams need to understand their velocity and burndown rate, so that they can steadily improve.

缺陷率是传统的软件指标，对于以零缺陷为目标的团队而言，它们可能没有太大价值。了解在开发过程中发现和修复错误的比率没有多大价值，因为发现和修复错误是开发过程中不可或缺的一部分。如果测试人员向正在处理代码的程序员展示了一个缺陷，并且编写了单元测试并立即修复了错误，则通常不需要记录缺陷。另一方面，如果许多缺陷在未被发现的情况下进入生产阶段，那么跟踪这些缺陷的数量以了解团队是否有所改进是有价值的。

Defect rates are traditional software metrics, and they might not have much value on a team that’s aiming for zero defects. There’s not much value in knowing the rate of bugs found and fixed during development, because finding and fixing them is an integral part of development. If a tester shows a defect to the programmer who’s working on the code, and a unit test is written and the bug is fixed right away, there’s often no need to log a defect. On the other hand, if many defects reach production undetected, there can be value in tracking the number to know if the team improves.

当它开始重写有缺陷的遗留应用程序时，Lisa 的团队设定了一个目标，即在新代码投入生产后六个月内报告的新代码中的高严重性缺陷不超过六个。拥有一个直接且易于跟踪的目标有助于激励团队找到在开发过程中阻止错误并超越该目标的方法。

When it started to rewrite its buggy legacy application, Lisa’s team set a goal of no more than six high-severity bugs in new code reported after the code is in production over a six-month period. Having a target that was straightforward and easy to track helped motivate the team to find ways to head bugs off during development and exceed this objective.

计算每个指标的投资回报率并决定是跟踪还是维护它。收集它所花费的努力是否证明它提供的价值是合理的？是否易于沟通和理解？一如既往，做适合你情况的事情。尝试在几个冲刺中保持特定的指标，并评估它是否有效。

Figure each metric’s return on investment and decide whether to track or maintain it. Does the effort spent collecting it justify the value it delivers? Can it be easily communicated and understood? As always, do what works for your situation. Experiment with keeping a particular metric for a few sprints and evaluate whether it’s paying off.

与软件质量相关的一种常见指标是缺陷率。在下一节中，我们将探讨跟踪缺陷或不跟踪缺陷的原因，以及我们可以从中学到什么。

One common metric that relates to software quality is the defect rate. In the next section, we look at reasons to track defects, or to not track defects, and what we can learn from them.

我们中的许多测试人员都将缺陷跟踪作为交流我们看到的问题的唯一方式，并且很容易继续使用我们熟悉的工具。DTS 是一个方便的地方，不仅可以跟踪缺陷，还可以跟踪优先级、严重性和状态，并查看它被分配给了谁。许多敏捷实践者说我们不需要再这样做了，我们可以通过卡片或其他一些简单的机制来跟踪缺陷。我们可以编写一个测试来显示失败，修复代码，并将测试保留在我们的回归套件中。

A lot of us testers have used defect tracking as the only way to communicate the issues we saw, and it’s easy to keep using the tools we are familiar with. A DTS is a convenient place to keep track of not only the defect but the priorities, severities, and status, and to see who it is assigned to. Many agile practitioners say that we don’t need to do this anymore, that we can track defects on cards or some other simple mechanism. We could write a test to show the failure, fix the code, and keep the test in our regression suite.

但是，有理由继续使用工具来记录缺陷及其修复方式。现在让我们探讨其中的一些。

However, there are reasons to keep using a tool to record defects and how they were fixed. Let’s explore some of them now.

敏捷和精益为我们提供了有助于减少对 DTS 需求的实践和原则。如果过程是可靠的，并且所有人都致力于提供高质量的产品，那么缺陷应该很少见并且很容易被跟踪。

Agile and Lean provide us with practices and principles that help reduce the need for a DTS. If the process is solid, and all of the people are committed to delivering a quality product, defects should be rare and very simply tracked.

如果您决定使用 DTS，请谨慎选择。了解您的需求并保持简单。您会希望团队中的每个人都使用它。如果它变得开销很大或难以使用，人们会想方设法解决它。对于敏捷开发团队使用的所有工具，您应该考虑整个团队的意见。如果客户团队的任何人输入错误报告，也请听取他或她的意见。

If you do decide to use a DTS, choose it carefully. Understand your needs and keep it simple. You will want everyone on the team to use it. If it becomes overhead or hard to use, people will find ways to work around it. As with all tools used by your agile development team, you should consider the whole team’s opinion. If anyone from the customer team enters bug reports, get his or her opinion too.

Janet 使用过的最简单的工具之一是 Alcea 的 FIT IssueTrack。它是可配置的，不会让您遵循预定义的流程，并且很容易从中获取指标。做好功课，找到适合您的工具。有多种开源缺陷跟踪系统、托管系统和集成企业系统可用。

One of the simplest tools that Janet has used is Alcea’s FIT IssueTrack. It is configurable, does not make you follow a predefined process, and is easy to get metrics out of. Do your homework and find the tool that works for you. There are a variety of open source defect-tracking systems, hosted systems, and integrated enterprise systems available.

无论您是否使用 DTS，您都希望缺陷尽可能可见。

Whether or not you use a DTS, you want to make defects as visible as possible.

我们使用商业 DTS，但我们发现保持错误可见的价值。我们对错误进行颜色编码，并将它们作为任务包含在我们的故事板中，如图5-1所示。黄牌表示正常错误，红牌表示高生产错误或“测试停止”开发错误——这两类都需要立即解决。快速查看看板可以让我们看到待办事项、WIP、验证和完成列中有多少错误。其他卡片也采用颜色编码：故事卡片为蓝色，测试任务卡片为绿色，开发任务卡片为白色。条纹卡片用于迭代计划后添加的任务。黄色和红色的虫子卡很容易脱颖而出。

We use a commercial DTS, but we find value in keeping bugs visible. We color-code bugs and include them as tasks in our story board, shown in Figure 5-1. Yellow cards denote normal bugs, and red cards denote either high production bugs or “test stopper” development bugs—both categories need to be addressed right away. A quick look at the board lets us see how many bugs are in the To Do, WIP, Verify and Done columns. Other cards are color-coded as well: blue for story cards, green for test task cards, and white for development tasks. Striped cards are for tasks added after iteration planning. Yellow and red bug cards stand out easily.

图 5-1带有颜色编码卡片的故事板。经 Mike Thomas 许可使用。版权所有 2008。

Figure 5-1 Story board with color-coded cards. Used with permission of Mike Thomas. Copyright 2008.

在我们写这本书的时候，我的团队转换为虚拟故事板，因为我们的一个团队成员成为了远程团队成员，但我们保留了这种颜色编码的概念。

During the time we were writing this book, my team converted to a virtual story board because one of our team members became a remote team member, but we retained this color-coding concept.

——丽莎

—Lisa

我们通常建议尝试使用不同的工具，使用每一种工具进行几次迭代，但这对于错误跟踪系统来说比较棘手，因为您需要将一个系统中的所有错误移植到您正在尝试的新系统中尺寸。花一些时间思考您在 DTS 中需要什么，它将服务于什么目的，并明智地评估备选方案。

We usually recommend experimenting with different tools, using each one for a few iterations, but this is trickier with bug-tracking systems, because you need to port all of the bugs that are in one system to the new one that you’re trying on for size. Spend some time thinking about what you need in a DTS, what purposes it will serve, and evaluate alternatives judiciously.

与所有工具搜索一样，向社区中的其他人（例如用户组和邮件列表）寻求建议。在开始寻找之前定义您的标准，并尽可能多地进行实验。如果您选择了错误的工具，请减少损失并开始研究替代品。

As with all your tool searches, look to others in your community, such as user groups and mailing lists, for recommendations. Define your criteria before you start looking, and experiment as much as you can. If you choose the wrong tool, cut your losses and start researching alternatives.

关于报告和跟踪缺陷的决定很重要，但不要忘记您的主要目标。您希望尽可能提供最优质的产品，并且希望及时为企业创造价值。项目当允许人们尽力而为时，就会成功。专注于改善沟通和建立协作。如果您遇到很多缺陷，请调查问题的根源。如果您需要 DTS 来执行此操作，请使用它。如果您的团队通过记录可执行测试中的缺陷并立即修复它们来更好地工作，那就去做吧。如果某种组合能让你不断改进，那就去吧。要记住的主要事情是它必须适用于您的整个团队。

Decisions about reporting and tracking defects are important, but don’t lose track of your main target. You want to deliver the best quality product you can, and you want to deliver value to the business in a timely manner. Projects succeed when people are allowed to do their best work. Concentrate on improving communication and building collaboration. If you encounter a lot of defects, investigate the source of the problem. If you need a DTS to do that, use it. If your team works better by documenting defects in executable tests and fixing them right away, do that. If some combination enables you continually improve, go with it. The main thing to remember is that it has to work for your whole team.

缺陷跟踪是敏捷测试中产生最多问题和争议的典型质量流程之一。混淆的另一个重要来源是敏捷项目是否需要测试计划或可追溯性矩阵等文档。接下来让我们考虑一下。

Defect tracking is one of the typical quality processes that generate the most questions and controversy in agile testing. Another big source of confusion is whether agile projects need documents such as test plans or traceability matrices. Let’s consider that next.

在敏捷项目中，团队不依赖大量文档来传达测试人员需要做什么。测试人员与团队的其他成员携手合作，以便测试工作以任务卡的形式对所有人可见。所以经常向我们提出的问题是，“是否还需要测试计划？” 要回答这个问题，让我们首先看一下测试计划和测试策略或方法之间的区别。

In an agile project, teams don’t rely on heavy documentation to communicate what the testers need to do. Testers work hand in hand with the rest of the team so that the testing efforts are visible to all in the form of task cards. So the question often put to us is, “Is there still a need for test plans?” To answer that question, let’s first take a look at the difference between a test plan and a test strategy or approach.

文档中包含的信息越多，有人阅读所有内容的可能性就越小。考虑利益相关者真正需要哪些信息。想想它的使用频率和用途。

The more information that is contained in a document, the less likely it is that someone is going to read it all. Consider what information is really necessary for the stakeholders. Think about how often it is used and what it is used for.

我们喜欢将测试策略视为很少更改的静态文档，而测试计划是新创建的并且特定于每个新项目。

We like to think of a test strategy as a static document that seldom changes, while a test plan is created new and is specific to each new project.

在传统项目中，我们过去常常需要可追溯性矩阵来确定我们是否实际测试了所有需求。如果需求发生变化，我们需要知道我们已经更改了适当的测试用例。对于非常大的需求文档，这是测试团队知道它具有良好覆盖率的唯一方式。

In traditional projects, we used to need traceability matrices to determine whether we had actually tested all of the requirements. If a requirement changed, we needed to know that we had changed the appropriate test cases. With very large requirements documents, this was the only way that a test team knew it had good coverage.

在敏捷项目中，我们没有这些限制。我们以微小的、定义明确的步骤构建功能。我们与团队密切合作，知道什么时候会发生变化。如果程序员先进行测试，我们就会知道所有小块工作都有单元测试。然后我们可以与客户合作定义验收测试。我们在程序员处理每个故事时对其进行测试，因此我们知道没有什么是未经测试的。

In an agile project, we don’t have those restrictions. We build functionality in tiny, well-defined steps. We work with the team closely and know when something changes. If the programmers work test-first, we know there are unit tests for all of the small chunks of work. We can then collaborate with the customer to define acceptance tests. We test each story as the programmer works on it, so we know that nothing goes untested.

受监管行业可能需要某种可追溯性。如果有，我们建议你真正看看问题管理试图解决什么问题。当您了解需要什么时，您应该尝试使解决方案尽可能简单。有多种方法可以提供可追溯性。源代码签入评论可以参考包含需求或测试用例的 wiki 页面，或者参考缺陷号。您可以在单元测试中添加注释，将测试与需求的位置或标识符联系起来。测试可以直接与 FitNesse 等工具中的需求集成。您的团队可以轻松找到最适合客户需求的方式。

There might be requirements for some kind of traceability for regulated industries. If there is, we suggest that you really look at what problem management is trying to solve. When you understand what is needed, you should try to make the solution as simple as possible. There are multiple ways to provide traceability. Source code check-in comments can refer to the wiki page containing the requirements or test cases, or to a defect number. You can put comments in unit tests tying the test to the location or identifier of the requirement. The tests can be integrated directly with the requirements in a tool such as FitNesse. Your team can easily find the way that works best for your customers’ needs.

可能需要诸如可追溯性矩阵之类的文件来满足组织的审计标准或质量模型强加的要求。让我们考虑一下这些指令如何与敏捷开发相得益彰。

Documents such as traceability matrices might be needed to fulfill requirements imposed by the organization’s audit standards or quality models. Let’s consider how these directives get along with agile development.

不同的行业有不同的审计要求。传统开发组织中的质量保证团队通常负责为审计员提供信息并确保符合审计要求。为应对引人注目的公司财务丑闻而颁布的 2002 年萨班斯-奥克斯利法案规定了维护业务记录的要求。确保合规性通常落在 IT 部门的肩上。SAS 70 是另一个广泛认可的服务组织审计标准。这些只是影响开发团队的审计控制类型的几个示例。

Different industries have different audit requirements. Quality assurance teams in traditional development organizations are often tasked with providing information for auditors and ensuring compliance with audit requirements. The Sarbanes-Oxley Act of 2002, enacted in response to high-profile corporate financial scandals, sets out requirements for maintaining business records. Ensuring compliance usually falls to the IT departments. SAS 70 is another widely recognized auditing standard for service organizations. These are just a couple of examples of the type of audit controls that affect development teams.

较大的组织有专门的团队来控制合规性并与审计员合作，但开发团队经常被要求提供信息。示例包括在给定的软件版本上执行了哪些测试，或证明不同的帐户协调一致。测试人员的任务是编写测试计划来评估控制活动的有效性。

Larger organizations have specialized teams that control compliance and work with auditors, but development teams are often asked to provide information. Examples include what testing has been performed on a given software release, or proving that different accounts reconcile. Testers can be tasked with writing test plans to evaluate the effectiveness of control activities.

属于敏捷团队的测试人员应该致力于该团队。如果需要他们的帮助来提供审计信息或帮助确保合规性，为此写故事，并与团队的其他工作一起计划。与合规和内部审计团队合作，了解您团队的职责。

Testers who are part of an agile team should be dedicated to that team. If their help is needed in providing information for an audit or helping to ensure compliance, write stories for this and plan them along with the rest of the team’s work. Work together with the compliance and internal audit teams to understand your team’s responsibilities.

质量模型有很多，但我们只看其中两个，以展示如何调整敏捷过程以适应它们的约束。

There are many quality models, but we’ll look at two to show how you can adapt your agile process to fit within their constraints.

1.能力成熟度模型集成 (CMMI) 旨在帮助组织改进他们的过程，但并不规定具体的开发实践来完成改进。

1. The Capability Maturity Model Integration (CMMI) aims to help organizations improve their process but doesn’t dictate specific development practices to accomplish the improvements.

2.信息技术基础架构库 (ITIL) 是一组 IT 服务管理最佳实践，旨在帮助组织开发有效的质量流程。

2. Information Technology Infrastructure Library (ITIL) is a set of best practices for IT service management intended to help organizations develop an effective quality process.

这两种模型都可以与敏捷开发愉快地共存。他们植根于同一个目标，即使软件开发项目取得成功。

Both of these models can coexist happily with agile development. They’re rooted in the same goal, making software development projects succeed.

让我们看看 CMMI，这是一个用于衡量流程成熟度的框架。它通过测量过程是未知的、已定义的、记录的、永久的还是优化的来定义每个级别。敏捷项目有一个明确的过程，尽管并非所有团队都记录他们所做的事情。例如，通过发布计划墙上的索引卡管理您的需求，并由单个客户做出最终决定，只要您一直这样做，就是一个明确的过程。

Let’s look at CMMI, a framework for measuring the maturity of your process. It defines each level by measuring whether the process is unknown, defined, documented, permanent, or optimized. Agile projects have a defined process, although not all teams document what they do. For example, managing your requirements with index cards on a release planning wall with a single customer making the final decisions is a defined process as long as you do it all the time.

回顾旨在不断改进流程，团队应该始终寻找优化流程的方法。如果您的团队唯一缺乏的是文档，那么请考虑将您的过程包含到您的测试策略文档中。

Retrospectives are aimed at constant process improvement, and teams should be always be looking for ways to optimize processes. If the only thing your team is lacking is documentation, then think about including your process into your test strategy documentation.

问问自己，满足 CMMI 要求的最少文档数量是多少。Janet 在使用图 5-2中的图表方面取得了成功。

Ask yourself what the minimum amount of documentation you could give to satisfy the CMMI requirements would be. Janet has had success with using diagrams like the one in Figure 5-2.

图 5-2记录测试策略

Figure 5-2 Documenting the test strategy

如果 ITIL 已被引入您的组织并影响变更管理，请调整您的流程以适应它。您甚至可能会发现新流程是有益的。

If ITIL has been introduced into your organization and affects change management, adapt your process to accommodate it. You might even find the new process beneficial.

如果您的组织正在使用某种流程模型或质量标准管理，请自行学习并与组织中合适的专家合作。保持团队专注于交付可提供真正业务价值的高质量软件，并了解您如何在模型中工作。

If your organization is using some kind of process model or quality standards management, educate yourself about it, and work with the appropriate specialists in your organization. Maintain the team’s focus on delivering high-quality software that provides real business value, and see how you can work within the model.

流程改进模型和框架强调流程的纪律和一致性。很少有软件开发方法比敏捷开发需要更多的纪律。标准只是让您能够衡量您实现目标的进度。敏捷的重点是尽力而为并不断改进。敏捷开发与实现您为自己设定的任何标准或从过程改进测量工具中借用的标准兼容。

Process improvement models and frameworks emphasize discipline and conformance to process. Few software development methodologies require more discipline than agile development. Standards simply enable you to measure your progress toward your goal. Agile’s focus is on doing your best work and constantly improving. Agile development is compatible with achieving whatever standards you set for yourself or borrow from a process improvement measurement tool.

将您的测量目标和标准与改进这些测量的方法分开。设定目标，并了解您需要哪些指标来衡量需要改进的领域是否成功。尝试使用任务卡提供改进的活动，以确保他们获得所需的可见性。

Separate your measurement goals and standards from your means to improve those measurements. Set goals, and know what metrics you need to measure success for areas that need improvement. Try using task cards for activities that provide the improvements in order to ensure they get the visibility they need.

使用现有的质量流程和模型是您在过渡到敏捷开发时可能面临的最大文化问题之一。所有这些改变都是艰难的，但是当你的整个团队都参与进来时，没有什么是不可克服的。

Working with existing quality processes and models is one of the biggest cultural issues you may face as you transition to agile development. All of these changes are hard, but when your whole team gets involved, none are insurmountable.

左侧的象限包括支持团队开发产品的测试。这种帮助程序员的测试概念对许多测试人员来说是新的，并且是传统项目测试与敏捷项目测试之间的最大区别。在象限 1 和 2 中完成的测试比我们通常认为的测试更多的是需求规范和设计辅助。

The quadrants on the left include tests that support the team as it develops the product. This concept of testing to help the programmers is new to many testers and is the biggest difference between testing on a traditional project and testing on an agile project. The testing done in Quadrants 1 and 2 are more requirements specification and design aids than what we typically think of as testing.

如果您一直担任客户角色并且必须表达您对软件功能的要求，您就会知道在您看到它之前要确切知道您想要什么是多么困难。即使您对该功能的工作方式有信心，也很难描述它以使程序员完全理解它。

If you’ve been in a customer role and had to express your requirements for a software feature, you know how hard it can be to know exactly what you want until you see it. Even if you’re confident about how the feature should work, it can be hard to describe it so that programmers fully understand it.

“批评”这个词并不具有消极意义。批评可以包括表扬和改进建议。评估软件产品涉及艺术和科学。我们以建设性的方式审查软件，目的是了解我们如何改进它。随着我们的学习，我们可以将新的需求和测试或示例反馈给支持团队和指导开发的流程。

The word “critique” isn’t intended in a negative sense. A critique can include both praise and suggestions for improvement. Appraising a software product involves both art and science. We review the software in a constructive manner, with the goal of learning how we can improve it. As we learn, we can feed new requirements and tests or examples back to the process that supports the team and guide development.

我们的产品团队需要广泛的专业知识来涵盖所有敏捷测试象限。程序员应该编写支持编程的面向技术的测试，但他们可能在不同时间需要测试人员、数据库设计人员、系统管理员和配置专家的帮助。测试人员与客户一起主要负责面向业务的测试，但程序员参与设计和自动化测试，同时可能会根据需要召集可用性专家和其他专家。第四象限，通过面向技术的测试来评判产品，可能需要更多的专家。无论必须从开发团队外部引入什么资源，该团队仍然负责完成所有四个象限的测试。

Our product teams need a wide range of expertise to cover all of the agile testing quadrants. Programmers should write the technology-facing tests that support programming, but they might need help at different times from testers, database designers, system administrators, and configuration specialists. Testers take primary charge of the business-facing tests in tandem with the customers, but programmers participate in designing and automating tests, while usability and other experts might be called in as needed. The fourth quadrant, with technology-facing tests that critique the product, may require more specialists. No matter what resources have to be brought in from outside the development team, the team is still responsible for getting all four quadrants of testing done.

我们相信，一个成功的团队是每个人都参与产品的制作，并且当出现问题时每个人都分担团队内部的痛苦。实施使我们能够的实践和工具解决所有四个象限的测试有时会很痛苦，但实现成功产品的乐趣是值得付出努力的。

We believe that a successful team is one where everybody participates in the crafting of the product and that everyone shares the team’s internal pain when things go wrong. Implementing the practices and tools that enable us to address all four quadrants of testing can be painful at times, but the joy of implementing a successful product is worth the effort.

单元测试和组件测试通过帮助程序员准确理解代码需要做什么以及通过提供指导来确保质量正确的设计。他们帮助团队专注于正在交付的故事，并采取最简单的方法。单元测试验证小到单个对象或方法的部件的行为 [ Meszaros, 2007 ]。组件测试通过测试类或方法之间的交互来帮助巩固系统可部署部分的整体设计。

Unit tests and component tests ensure quality by helping the programmer understand exactly what the code needs to do, and by providing guidance in the right design. They help the team to focus on the story that’s being delivered and to take the simplest approach that will work. Unit tests verify the behavior of parts as small as a single object or method [Meszaros, 2007]. Component tests help solidify the overall design of a deployable part of the system by testing the interaction between classes or methods.

在使用 TDD 时，开发单元测试可能是必不可少的设计工具。当敏捷程序员开始编码任务时，她会编写一个测试来捕获一小段代码的行为，然后处理代码直到测试通过。通过以小的测试-代码-测试增量构建代码，程序员有机会全面考虑客户需要的功能。出现问题时，她可以询问客户。她可以与测试人员配对，以帮助确保该段代码的所有方面及其与其他单元的通信都经过测试。

Developing unit tests can be an essential design tool when using TDD. When an agile programmer starts a coding task, she writes a test that captures the behavior of a tiny bit of code and then works on the code until the test passes. By building the code in small test-code-test increments, the programmer has a chance to think through the functionality that the customer needs. As questions come up, she can ask the customer. She can pair with a tester to help make sure all aspects of that piece of code, and its communication with other units, are tested.

测试驱动开发这个术语会误导那些不明白它更多的是设计而不是测试的从业者。测试先行开发的代码自然是为可测试性而设计的。象限 1 的活动都旨在生产具有尽可能高的内部质量的软件。

The term test-driven development misleads practitioners who don’t understand that it’s more about design than testing. Code developed test-first is naturally designed for testability. Quadrant 1 activities are all aimed at producing software with the highest possible internal quality.

当团队实践 TDD 时，他们会最大限度地减少以后必须发现的错误数量。通过在代码之前编写测试来防止大多数单元级错误。通过编写单元测试来思考设计意味着系统更有可能满足客户的要求。当后期开发测试时间被用于查找和修复程序员测试可能检测到的错误时，就没有时间查找可能对业务产生不利影响的严重问题。从我们的编码过程中泄漏的错误越多，我们的交付就会越慢，最终，质量会受到影响。这就是象限 1 中的程序员测试如此重要的原因。虽然每个团队都应该采用适合其情况的做法，

When teams practice TDD, they minimize the number of bugs that have to be caught later on. Most unit-level bugs are prevented by writing the test before the code. Thinking through the design by writing the unit test means the system is more likely to meet customer requirements. When post-development testing time is occupied with finding and fixing bugs that could have been detected by programmer tests, there’s no time to find the serious issues that might adversely affect the business. The more bugs that leak out of our coding process, the slower our delivery will be, and in the end, it is the quality that will suffer. That’s why the programmer tests in Quadrant 1 are so critical. While every team should adopt practices that work for its situation, a team without these core agile practices is unlikely to benefit much from agile values and principles.

可靠的源代码控制、配置管理和持续集成对于从指导开发的程序员测试中获取价值至关重要。它们使团队始终能够准确了解正在测试的内容。持续集成为我们提供了一种在每次签入新代码时运行测试的方法。当测试失败时，我们知道是谁签入了导致失败的更改，并且那个人可以快速解决问题。连续的集成节省了时间并激励每个程序员在签入新代码之前运行测试。持续集成和构建过程提供了一个可部署的代码包供我们测试。

Solid source code control, configuration management, and continuous integration are essential to getting value from programmer tests that guide development. They enable the team to always know exactly what’s being tested. Continuous integration gives us a way to run tests every time new code is checked in. When a test fails, we know who checked in the change that caused the failure, and that person can quickly fix the problem. Continuous integration saves time and motivates each programmer to run the tests before checking in the new code. A continuous integration and build process delivers a deployable package of code for us to test.

缺乏这些核心敏捷实践的敏捷项目往往会变成“迷你瀑布”。开发周期更短了，但代码仍然被“翻墙”扔给测试人员，因为代码质量很差，他们没有时间进行测试。瀑布这个词不一定是贬义的。我们从事过成功的“瀑布式”项目，在这些项目中，程序员严格自动化单元测试，实践持续集成，并使用自动化构建来运行测试。这些成功的“瀑布式”项目还涉及整个开发周期的客户和测试人员。当我们在没有适当的实践和工具的情况下进行编码时，无论我们如何称呼这个过程，我们都不会及时交付高质量的代码。

Agile projects that lack these core agile practices tend to turn into “mini-waterfalls.” The development cycles are shorter, but code is still being thrown “over the wall” to testers who run out of time to test because the code is of poor quality. The term waterfall isn’t necessarily derogatory. We’ve worked on successful “waterfall” projects where the programmers stringently automate unit tests, practice continuous integration, and use automated builds to run tests. These successful “waterfall” projects also involve customers and testers throughout the development cycle. When we code without appropriate practices and tools, regardless of what we call the process, we’re not going to deliver high-quality code in a timely manner.

速度永远不应该是敏捷开发团队的最终目标。试图快速做事并在紧迫的期限内完成任务而不考虑质量会导致我们偷工减料并重拾旧有的坏习惯。如果我们偷工减料，我们就会积累更多的技术债务，并且可能无论如何都会错过最后期限。令人高兴的是，速度是生成具有最高内部质量的代码的长期副作用。持续构建运行单元测试会在问题签入后的几分钟内通知团队失败，并且可以快速找到并修复错误。自动化单元和代码集成测试的安全网使程序员能够经常重构。这使代码保持在合理的可维护性标准，并为投入的时间提供最佳价值。技术债务保持在尽可能低的水平。

Speed should never be the end goal of an agile development team. Trying to do things fast and meet tight deadlines without thinking about the quality causes us to cut corners and revert to old, bad habits. If we cut corners, we’ll build up more technical debt, and probably miss the deadline anyway. Happily, though, speed is a long-term side effect of producing code with the highest possible internal quality. Continuous builds running unit tests notify the team of failure within a few minutes of the problem check-in, and the mistake can be found and fixed quickly. A safety net of automated unit and code integration tests enables the programmers to refactor frequently. This keeps the code at a reasonable standard of maintainability and delivers the best value for the time invested. Technical debt is kept as low as possible.

如果您在一个忽略了单元测试的项目中担任过测试人员，您就会知道将所有时间都花在查找单元级缺陷上是多么容易。在测试“快乐路径”时，您可能会发现如此多的错误，以至于您永远没有时间测试更复杂的场景和边缘情况。随着“查找和修复”周期的拖延，发布截止日期被推迟，或者测试刚刚停止并且有缺陷的产品被强加给毫无戒心的客户。

If you’ve worked as a tester on a project where unit testing was neglected, you know how easy it is to spend all of your time finding unit-level defects. You might find so many bugs while testing the “happy path” that you never have time to test more complex scenarios and edge cases. The release deadline is pushed back as the “find and fix” cycle drags on, or testing is just stopped and a buggy product is foisted off on unsuspecting customers.

与这种情况相比，我们在敏捷团队中的岁月一直是乌托邦。通过测试推动编码实践意味着程序员可能相当了解故事的要求。他们与客户和测试人员进行了广泛的交谈，以阐明所需的行为。各方都了解正在进行的更改。当团队完成编写一个故事的所有任务卡，或一个薄的、可测试的片段时，单元和组件测试已经很好地覆盖了该功能。通常，程序员已经确保故事中至少有一条路径可以从头到尾运行。

Our years on agile teams have been Utopian in contrast to this scenario. Driving coding practices with tests means that the programmers probably understood the story’s requirements reasonably well. They’ve talked extensively with the customers and testers to clarify the desired behaviors. All parties understand the changes being made. By the time the team has completed all of the task cards for coding a story, or a thin, testable slice of one, the feature has been well covered by unit and component tests. Usually the programmers have made sure at least one path through the story works end to end.

这意味着我们作为测试人员几乎不会浪费时间寻找低级错误。我们可能会尝试程序员没有想到的场景，并将时间花在更高级别的业务功能上。设计良好的代码通常是健壮的和可测试的。如果我们发现缺陷，我们会把它展示给程序员，程序员编写单元测试来重现错误，然后快速修复它。实际上，我们有时间专注于探索性测试和其他类型的深入测试，以便对代码进行良好的锻炼，并了解更多关于它应该如何工作的信息。通常，我们发现的唯一“错误”是我们团队中的每个人都错过或误解的要求。如果客户参与并有定期的演示和测试机会，即使是那些也能很快找到。开发团队掌握 TDD 后，

This means that we, as testers, waste little time finding low-level bugs. We’re likely to try scenarios the programmers hadn’t thought of and to spend our time on higher-level business functionality. Well-designed code is usually robust and testable. If we find a defect, we show it to the programmer, who writes a unit test to reproduce the bug and then fixes it quickly. We actually have time to focus on exploratory testing and the other types of in-depth tests to give the code a good workout and learn more about how it should work. Often, the only “bugs” we find are requirements that everyone on our team missed or misunderstood. Even those are found quickly if the customer is involved and has regular demos and test opportunities. After a development team has mastered TDD, the focus for improvement shifts from bug prevention to figuring out better ways to elicit and capture requirements before coding.

关于何时编写测试以及出于什么目的，存在多种不同的理念。尽管敏捷社区普遍认为 TDD 确实可以帮助团队实现质量更好的软件，但每个团队都应就有助于其实现质量目标的方法达成一致。这是程序员测试支持团队的重要方式。让我们看看更多的方法。

There are several different philosophies about when to write tests and for what purpose. It’s up to each team to agree on the approach that helps it achieve its quality objectives, although there is common agreement in the agile community that TDD definitely helps a team achieve better-quality software. This is an important way that programmer tests support the team. Let’s look at some more ways.

与程序员测试相关的核心实践使许多测试活动更容易完成。程序员在他们自己的沙盒中工作，他们可以在其中测试新代码而不影响其他人的工作。他们不会签入代码，直到代码在他们的沙箱中通过了一套回归测试。

The core practices related to programmer tests make lots of testing activities easier to accomplish. Programmers work in their own sandboxes, where they can test new code without affecting anyone else’s work. They don’t check in code until it has passed a suite of regression tests in their sandbox.

团队考虑测试环境以及测试数据使用什么。单元测试通常使用假对象或模拟对象而不是实际数据库来提高速度，但程序员仍然需要针对真实数据进行测试。测试人员可以帮助他们识别好的测试数据。如果单元测试代表现实生活中的数据，以后发现的问题就会更少。

The team thinks about test environments and what to use for test data. Unit tests usually work with fake or mock objects instead of actual databases for speed, but programmers still need to test against realistic data. Testers can help them identify good test data. If the unit tests represent real-life data, fewer issues will be found later.

编写测试和编写代码时考虑到这些测试意味着程序员总是有意识地使代码可测试。所有这些与基础架构相关的良好品质都会溢出到面向业务的测试和批评产品的测试中。整个团队一直在思考改进设计和简化测试的方法。

Writing tests and writing code with those tests in mind means programmers are always consciously making code testable. All of these good infrastructure-related qualities spill over to business-facing tests and tests that critique the product. The whole team is continually thinking of ways to improve design and make testing easier.

用测试驱动开发的优势之一是编写代码的目的是让测试通过。团队必须从一开始就考虑如何为其编码的每个故事执行和自动化测试。测试驱动开发意味着程序员在编写代码之前会编写每个测试以使其通过。

One advantage of driving development with tests is that code is written with the express intention of making the tests pass. The team has to think, right from the beginning, about how it will execute and automate tests for every story it codes. Test-driven development means that programmers will write each test before they write the code to make it pass.

编写“可测试的代码”是一个简单的概念，但这并不是一件容易的事，尤其是当您正在处理没有自动测试且不是为可测试性而设计的旧代码时。遗留系统通常将业务逻辑、I/O、数据库和用户界面层交织在一起。没有简单的方法来挂钩以在 GUI 下或单元级别自动化测试。

Writing “testable code” is a simple concept, but it’s not an easy task, especially if you’re working on old code that has no automated tests and isn’t designed for testability. Legacy systems often have business logic, I/O, database, and user interface layers intertwined. There’s no easy way to hook in to automate a test below the GUI or at the unit level.

设计可测试架构的常用方法是将应用程序中执行不同功能的不同层分开。理想情况下，您希望使用测试夹具和具有不同输入的测试算法直接访问每一层。为此，您将业务逻辑隔离到它自己的层中，使用假对象而不是尝试访问其他应用程序或实际数据库。如果可以将表示层与底层业务逻辑和数据库访问分离，则可以在不测试底层逻辑的情况下快速测试输入验证。

A common approach in designing a testable architecture is to separate the different layers that perform different functions in the application. Ideally, you would want to access each layer directly with a test fixture and test algorithms with different inputs. To do this, you isolate the business logic into its own layer, using fake objects instead of trying to access other applications or the actual database. If the presentation layer can be separated from underlying business logic and database access, you can quickly test input validation without testing underlying logic.

可测试设计方法的另一个例子是 Alistair Cockburn 的端口和适配器模式 [Cockburn, 2005]。此模式的目的是“创建无需 UI 或数据库即可工作的应用程序，以便您可以针对应用程序运行自动回归测试，在数据库不可用时工作，并将应用程序链接在一起而无需任何用户参与。” 端口接受外部事件，特定技术的适配器将其转换为应用程序可以理解的消息。反过来，应用程序通过端口将输出发送到适配器，适配器创建接收人员或自动用户所需的信号。使用此模式设计的应用程序可以像实际用户一样轻松地由自动化测试脚本驱动。

Another example of an approach to testable design is Alistair Cockburn’s Ports and Adapters pattern [Cockburn, 2005]. This pattern’s intent is to “create your application to work without either a UI or a database so you can run automated regression tests against the application, work when the database becomes unavailable, and link applications together without any user involvement.” Ports accept outside events, and a technology-specific adapter converts it into a message that can be understood by the application. In turn, the application sends output via a port to an adapter, which creates the signals needed by the receiving human or automated users. Applications designed using this pattern can be driven by automated test scripts as easily as by actual users.

更明显的是如何在未开发项目上编写测试先行的代码。自动化单元测试未涵盖的遗留系统提出了巨大的挑战。很难为不是为可测试性而设计的代码编写单元测试，也很难更改不受单元测试保护的代码。很多球队都有遵循 Michael Feathers 在Working Effectively with Legacy Code [Feathers, 2004]中解释的“遗留代码救援”技术。其他团队，例如 Lisa 的团队，旨在“扼杀”他们的遗留代码。该策略源于 Martin Fowler 的“扼杀器应用程序”[ Fowler, 2004 ]。在仍然维护旧系统的同时，新故事在新架构中以测试优先的方式编码。随着时间的推移，系统的大部分已转换为新架构，目标是最终废除旧系统。

It’s more obvious how to code test-first on a greenfield project. Legacy systems, which aren’t covered by automated unit tests, present a huge challenge. It’s hard to write unit tests for code that isn’t designed for testability, and it’s hard to change code that isn’t safeguarded with unit tests. Many teams have followed the “legacy code rescue” techniques explained by Michael Feathers in Working Effectively with Legacy Code [Feathers, 2004]. Other teams, such as Lisa’s, aim to “strangle” their legacy code. This strategy stems from Martin Fowler’s “strangler application” [Fowler, 2004]. New stories were coded test-first in a new architecture while the old system was still maintained. Over time, much of the system has been converted to the new architecture, with the goal of eventually doing away with the old system.

在遗留大型机类型的环境中进行敏捷测试会带来特殊的挑战，其中最重要的是缺乏有关如何成功进行测试的出版物和信息。COBOL、大型机及其同类产品仍在广泛使用。当您寻找在应用程序中启用自动化测试的方法时，让敏捷原则和价值观指导您的团队。您可能需要调整一些技巧；例如，也许你不能写代码测试先行，但你可以在写完代码后马上进行测试。当需要解决的是团队的问题，而不仅仅是测试人员的问题时，您就会找到编写测试的方法。

Agile testing in a legacy mainframe type of environment presents particular challenges, not the least of which is the lack of availability of publications and information about how to do it successfully. COBOL, mainframes, and their ilk are still widely used. Let agile principles and values guide your team as you look for ways to enable automated testing in your application. You might have to adapt some techniques; for example, maybe you can’t write code test-first, but you can test soon after writing the code. When it’s the team’s problem to solve, and not just the testers’ problem, you’ll find a way to write tests.

您的团队可以找到适合您的可测试性设计方法。秘诀在于整个团队对测试和质量的承诺。当一个团队不断努力编写测试并使它们通过时，它就会找到完成它的方法。团队应该花时间考虑他们如何创建一个架构，使自动化测试易于创建、维护成本低且寿命长。如果自动化测试没有为投资回报足够的价值，不要害怕重新审视架构。

Your team can find an approach to designing for testability that works for you. The secret is the whole-team commitment to testing and quality. When a team is constantly working to write tests and make them pass, it finds a way to get it done. Teams should take time to consider how they can create an architecture that will make automated tests easy to create, inexpensive to maintain, and long-lived. Don’t be afraid to revisit the architecture if automated tests don’t return enough value for the investment in them.

单元测试的最大价值在于其反馈的速度。我们认为，运行单元测试的持续集成和构建过程应该在十分钟内完成。如果每个程序员每天检查代码几次，那么较长的构建和测试过程将导致更改开始堆积。作为测试人员，不得不长时间等待新功能或错误修复可能会令人沮丧。如果出现编译错误或单元测试失败，延迟会变得更糟，尤其是快到回家的时候了！

The biggest value of unit tests is in the speed of their feedback. In our opinion, a continuous integration and build process that runs the unit tests should finish within ten minutes. If each programmer checks code in several times a day, a longer build and test process will cause changes to start stacking up. As a tester, it can be frustrating to have to wait a long time for new functionality or a bug fix. If there’s a compile error or unit test failure, the delay gets even worse, especially if it’s almost time to go home!

在单元级别之上运行测试的构建和测试过程（例如功能性 API 测试或 GUI 测试）将花费更长的时间。至少有一个快速运行的构建过程，第二个运行较慢的测试。应该至少有一个每日“构建”来运行所有较慢的功能测试。然而，即使那样也可能很笨拙。当测试失败并且问题得到解决时，需要多长时间才能确定构建再次通过？

A build and test process that runs tests above the unit level, such as functional API tests or GUI tests, is going to take longer. Have at least one build process that runs quickly, and a second that runs the slower tests. There should be at least one daily “build” that runs all of the slower functional tests. However, even that can be unwieldy. When a test fails and the problem is fixed, how long will it take to know for sure that the build passes again?

如果您的构建和测试过程花费的时间太长，请让您的团队分析减速的原因并采取措施加快构建速度。这里有一些例子。

If your build and test process takes too long, ask your team to analyze the cause of the slowdown and take steps to speed up the build. Here are a few examples.

哇，多个连续的构建和测试过程提供持续的反馈——这对很多测试人员来说听起来像是一个梦想。回归错误将在修复成本最低的时候及早发现。这是编写面向技术的测试的重要原因。但是，我们会不会对他们太着迷了？让我们看看面向技术的测试和面向业务的测试之间的界限。

Wow, multiple continuous build and test processes providing constant feedback—it sounds like a dream to a lot of testers. Regression bugs will be caught early, when they’re cheapest to fix. This is a great reason for writing technology-facing tests. Can we get too carried away with them, though? Let’s look at the line between technology-facing tests and business-facing tests.

如果您是所谓的“敏捷”团队中的测试人员，该团队甚至不执行单元测试自动化或生成连续构建（或者至少不每天进行构建），您很快就会感到沮丧。不要放弃；继续集思广益，寻找一种方法来推动积极的转变。尝试利用社交时间或其他放松活动来花一些时间，看看您可以产生哪些新想法来让所有团队成员参与进来。

If you’re a tester on a so-called “agile” team that isn’t even automating unit tests or producing continuous builds—or at a minimum, doing builds on a daily basis—you’re going to get frustrated pretty quickly. Don’t give up; keep brainstorming for a way to get traction on a positive transition. Try using social time or other relaxing activity to take some quality time to see what new ideas you can generate to get all team members on board.

要避免的一个陷阱是让测试人员编写单元测试。因为 TDD 实际上更像是一种设计活动，所以编写代码的人在编写代码之前也必须编写测试。程序员还需要自动化单元测试提供的即时反馈。在编写代码后由其他人编写的单元测试可能仍然可以防止回归缺陷，但它们不会获得程序员编写的测试的最有价值的好处。

One trap to avoid is having testers write the unit tests. Because TDD is reallymore of a design activity, it’s essential that the person writing the code also write the tests, before writing the code. Programmers also need the immediate feedback that automated unit tests give. Unit tests written by someone else after the code is written might still guard against regression defects, but they won’t have the most valuable benefits of tests written by the programmer.

作为敏捷团队的测试人员，您可以做很多事情来充当变更推动者，但您的潜在影响是有限的。在某些情况下，强大的管理支持是推动团队从事第一象限活动的关键。

As a tester on an agile team, there’s a lot you can do to act as a change agent, but your potential impact is limited. In some cases, strong management support is the key to driving the team to engage in Quadrant 1 activities.

如果您正在管理一个开发团队，您可以做很多事情来鼓励测试驱动开发和单元测试自动化。与产品负责人合作，将质量作为您的目标，并将质量标准传达给团队。鼓励程序员花时间把工作做到最好，而不是担心赶不上最后期限。如果交货日期处于危险之中，则推动缩小范围，而不是质量。你的工作是向业务经理解释将质量放在首位将如何确保他们获得最佳业务价值。

If you’re managing a development team, you can do a lot to encourage test-driven development and unit test automation. Work with the product owner to make quality your goal, and communicate the quality criteria to the team. Encourage the programmers to take time to do their best work instead of worrying about meeting a deadline. If a delivery date is in jeopardy, push to reduce the scope, not the quality. Your job is to explain to the business managers how making quality a priority will ensure that they get optimum business value.

给团队时间学习，并提供专业的实践培训。引入经验丰富的敏捷开发教练或聘请具有使用这些实践经验的人，他们可以将这些技能传授给团队的其他成员。为重大重构、就编写单元和代码集成测试的最佳方法集思广益以及评估、安装和升级工具安排时间。测试经理应该与开发一起工作管理人员鼓励增强可测试性并允许测试人员编写可执行测试的实践。测试经理还可以确保测试人员有时间学习如何使用团队决定实施的自动化工具和框架。

Give the team time to learn, and provide expert, hands-on training. Bring in an experienced agile development coach or hire someone with experience in using these practices who can transfer those skills to the rest of the team. Budget time for major refactoring, for brainstorming about the best approach to writing unit and code integration tests, and for evaluating, installing, and upgrading tools. Test managers should work with development managers to encourage practices that enhance testability and allow testers to write executable tests. Test managers can also make sure testers have time to learn how to use the automation tools and frameworks that the team decides to implement.

虽然您可以找到成为有效变革推动者的方法，但最好的办法是让整个团队参与解决问题。如果您还没有在每次迭代后进行回顾，建议尝试这种做法或其他类型的流程改进。在回顾中，提出阻碍成功交付的问题。例如，“我们没有在迭代结束前完成测试任务”是整个团队要解决的问题。如果未完成的原因之一是大量的单元级错误，建议尝试使用 TDD，但允许程序员提出他们自己的解决问题的方法。鼓励团队尝试一种新方法进行几次迭代，看看它是如何工作的。

While you can find ways to be an effective change agent, the best thing to do is involve the whole team in solving the problems. If you aren’t already doing retrospectives after every iteration, propose trying this practice or some other type of process improvement. At the retrospective, raise issues that are hampering successful delivery. For example, “We aren’t finishing testing tasks before the end of the iteration” is a problem for the whole team to address. If one reason for not finishing is the high number of unit-level bugs, suggest experimenting with TDD, but allow programmers to propose their own ways to address the problem. Encourage the team to try a new approach for a few iterations and see how it works.

支持团队开发过程的面向技术的测试是所有需要进行的测试的重要基础。如果团队在这个象限中的测试做得不够好，那么其他类型的测试就会困难得多。这并不意味着你不能从其他象限中单独获得价值——这只是意味着这样做会更难，因为团队的代码将缺乏内部质量，一切都将花费更长的时间。

Technology-facing tests that support the team’s development process are an important foundation for all of the testing that needs to happen. If the team isn’t doing an adequate job with the tests in this quadrant, the other types of testing will be much more difficult. This doesn’t mean you can’t get value from the other quadrants on their own—it just means it will be harder to do so because the team’s code will lack internal quality and everything will take longer.

没有正确的工具和基础设施，就无法完成面向技术的测试。在下一节中，我们将查看团队需要有效进行象限 1 测试的工具类型的示例。

Technology-facing tests can’t be done without the right tools and infrastructure. In the next section, we look at examples of the types of tools a team needs to be effective with Quadrant 1 tests.

源代码控制也有其他名称，例如版本控制或修订控制。它当然不是新的，也不是敏捷开发所独有的，但是没有它，任何软件开发团队都无法成功。这就是我们在这里讨论它的原因。如果没有源代码控制，您将永远无法确定您正在测试的是什么。程序员是只更改了他说他更改的模块，还是忘记了他对其他模块所做的更改？如果没有某种版本控制系统，您将无法撤销不需要的或错误的更改。源代码控制可以防止不同的程序员在同一模块上互相修改。如果没有版本控制，您将无法确定将哪些代码发布到生产环境中。

Source code control is known by other names too, such as version control or revision control. It’s certainly not new, or unique to agile development, but no software development team can succeed without it. That’s why we’re discussing it here. Without source code control, you’ll never be sure what you’re testing. Did the programmer change only the module he said he changed, or did he forget changes he made to other modules? You can’t back out unwanted or erroneous changes without some kind of versioning system. Source code control keeps different programmers from walking on each other’s changes to the same modules. Without versioning, you can’t be sure what code to release to production.

Software Configuration Management Patterns: Effective Teamwork, Practical Integrations [ 2003 ]，作者 Stephen Berczuk 和 Brad Appleton，是学习如何以及为什么使用源代码控制的好资源。源代码控制对于任何风格的软件开发都是必不可少的。

Software Configuration Management Patterns: Effective Teamwork, Practical Integrations [2003], by Stephen Berczuk and Brad Appleton, is a good resource to use to learn how and why to use source code control. Source code control is essential to any style of software development.

也对自动化测试脚本使用源代码控制。将自动化测试与他们测试的相应代码版本联系起来很重要，以防您将来需要针对该版本重新运行测试。当您标记或标记构建时，请确保您也标记或标记测试代码，即使它没有发布到生产环境。

Use source code control for automated test scripts, too. It’s important to tie the automated tests with the corresponding code version that they tested in case you need to rerun tests against that version in the future. When you label or tag a build, make sure you label or tag the test code too, even if it doesn’t get released to production.

团队可以组织他们的代码层次结构，为生产代码、相应的单元测试和更高级别的测试脚本提供存储库。这样做可能需要一些头脑风暴和试验才能获得正确的结构。

Teams can organize their code hierarchy to provide a repository for production code, corresponding unit tests, and higher-level test scripts. Doing this might require some brainstorming and experimenting in order to get the right structure.

有许多很棒的选项可供选择。CVS 和 Subversion (SVN) 等开源系统易于实施，与持续构建过程和 IDE 集成，并且非常健壮。IBM Rational ClearCase 和 Perforce 等供应商工具可能会添加一些功能来补偿它们经常带来的增加的开销。

There are many terrific options to choose from. Open source systems such as CVS and Subversion (SVN) are easy to implement, integrate with a continuous build process and IDEs, and are robust. Vendor tools such as IBM Rational ClearCase and Perforce might add features that compensate for the increased overhead they often bring.

源代码控制与开发环境紧密集成。让我们看一下敏捷团队使用的一些 IDE。

Source code control is tightly integrated with development environments. Let’s look at some IDEs used by agile teams.

一个好的IDE（集成开发环境）可以帮助敏捷团队中的程序员和测试人员。IDE 与源代码控制系统集成，有助于防止版本控制问题和更改相互影响。IDE 内的编辑器特定于编程语言，即使在您编写代码时也会标记错误。最重要的是，IDE 提供了对重构的支持。

A good IDE (integrated development environment) can be helpful for programmers and testers on an agile team. The IDE integrates with the source code control system to help prevent problems with versioning and changes walking on each other. The editors inside an IDE are specific to the programming language and flag errors even as you write the code. Most importantly, IDEs provide support for refactoring.

使用 IDE 的程序员往往具有强烈的个人偏好。但是，有时组织会规定所有程序员都必须使用特定的 IDE。这可能是因为许可，也可能是为了鼓励开放结对编程。如果另一个程序员使用相同的 IDE，则与另一个程序员配对会更容易，但通常不必使用相同的 IDE。大多数工具的工作原理相似，因此不难从一种 IDE 更改为另一种 IDE 以满足新需求或利用新功能。一些顽固分子仍然更喜欢使用经过验证的技术，例如 vi、vim 或带有 make 文件的 emacs 而不是 IDE。

Programmers who use an IDE tend to have strong personal preferences. However, sometimes an organization decrees that all programmers must use a specific IDE. This might be because of licensing, or it might be intended to encourage open pair programming. It is easier to pair with another programmer if the other person uses the same IDE, but it’s generally not essential for the same one to be used. Most tools work similarly, so it’s not hard to change from one IDE to another in order to meet new needs or take advantage of new features. Some diehards still prefer to use tried-and-true technology such as vi, vim, or emacs with make files rather than an IDE.

Eclipse 和 NetBeans 等开源 IDE 以及 Visual Studio 和 IntelliJ IDEA 等专有系统被敏捷团队广泛使用。IDE 具有支持不同语言和工具的插件。它们在测试脚本中的表现与在生产代码中的表现一样好。

Open source IDEs such as Eclipse and NetBeans are widely used by agile teams, along with proprietary systems such as Visual Studio and IntelliJ IDEA. IDEs have plug-ins to support different languages and tools. They work as well with test scripts as they do with production code.

不通过 IDE 进行自动化测试但希望能够查看更改的代码片段的测试人员可以使用 FishEye 等工具，使测试人员能够通过自动构建访问代码。

Testers who aren’t automating tests through an IDE, but who want to be able to look at changed snippets of code, can use tools such as FishEye that enable the testers to get access to the code through the automated build.

在撰写本文时，IDE 已经添加了对动态语言（例如 Ruby、Groovy 和 Python）的支持。使用动态语言的程序员可能更喜欢轻量级的工具，但他们仍然需要支持良好编码实践的好工具，例如 TDD 和重构。

As of this writing, IDEs have added support for dynamic languages such as Ruby, Groovy, and Python. Programmers who use dynamic languages may prefer lighter-weight tools, but they still need good tools that support good coding practices, such as TDD and refactoring.

无论使用何种开发环境和工具，敏捷团队都需要一个框架来集成来自不同程序员的代码更改，运行单元测试以验证没有发生回归错误，并以可部署的格式提供代码。

Regardless of the development environment and tools being used, agile teams need a framework that will integrate code changes from different programmers, run the unit tests to verify no regression bugs have occurred, and provide the code in a deployable format.

您的团队需要一些方法来构建软件并创建可部署的 jar、war 或其他类型的文件。这可以使用基于 shell 的工具（例如 make）来完成，但是这些工具有局限性，例如它们工作的平台。我们知道的敏捷团队使用 ant、Nant 和 Maven 等工具来构建他们的项目。这些工具不仅可以管理构建，还可以提供报告和记录构建结果的简便方法，并且可以轻松地与构建自动化和测试工具集成。它们还与 IDE 集成。

Your team needs some way to build the software and create a deployable jar, war, or other type of file. This can be done with shell-based tools such as make, but those tools have limitations, such as the platforms where they work. Agile teams that we know use tools such as ant, Nant, and Maven to build their projects. These tools not only manage the build but also provide easy ways to report and document build results, and they integrate easily with build automation and test tools. They also integrate with IDEs.

持续集成是敏捷团队的核心实践。您需要一种方法，不仅可以构建项目，还可以对每个构建运行自动化测试，以确保没有任何问题。每天运行多次的完全自动化且可重现的构建是敏捷团队成功的关键因素。自动化构建工具提供构建结果的电子邮件通知等功能，并且它们与构建和源代码控制工具集成。

Continuous integration is a core practice for agile teams. You need a way to not only build the project but also run automated tests on each build to make sure nothing broke. A fully automated and reproducible build that runs many times a day is a key success factor for agile teams. Automated build tools provide features such as email notification of build results, and they integrate with build and source code control tools.

在撰写本书时常用的工具包括开源工具 CruiseControl、CruiseControl.net、CruiseControl.rb 和 Hudson。发布时可用的其他开源和专有工具包括 AnthillPro、Bamboo、BuildBeat、CI Factory、Team City 和 Pulse，仅举几例。

Commonly used tools as of the writing of this book include the open source tools CruiseControl, CruiseControl.net, CruiseControl.rb, and Hudson. Other open source and proprietary tools available at publication time are AnthillPro, Bamboo, BuildBeat, CI Factory, Team City, and Pulse, just to name a few.

如果没有自动构建过程，您将很难部署用于测试和发布的代码。构建管理和构建自动化工具易于实施，并且对于成功的敏捷项目绝对必要。确保尽早开始构建过程，甚至在开始编码之前。当您发现您需要的功能比当前流程提供的更多时，请尝试使用不同的工具。

Without an automated build process you’ll have a hard time deploying code for testing as well as releasing. Build management and build automation tools are easy to implement and absolutely necessary for successful agile projects. Make sure you get your build process going early, even before you start coding. Experiment with different tools when you find you need more features than your current process provides.

单元测试工具特定于您编写代码所用的语言。“xUnit”工具通常被敏捷团队使用，并且有许多不同语言的风格，包括用于 Java 的 JUnit、用于 .NET 的 NUnit、用于 Perl 和 Ruby 的 Test::Unit 以及用于 Python 的 PyUnit。

Unit test tools are specific to the language in which you’re coding. “xUnit” tools are commonly used by agile teams, and there’s a flavor for many different languages, including JUnit for Java, NUnit for .NET, Test::Unit for Perl and Ruby, and PyUnit for Python.

行为驱动开发是测试驱动开发的另一种形式，使用 RSpec 和 easyb 等工具阐明预期行为以驱动测试。

Behavior-driven development is another flavor of test-driven development, spelling out expected behavior to drive tests with tools such as RSpec and easyb.

GUI 代码也可以而且应该以测试先行的方式开发。用于富客户端单元测试的一些工具是 TestNG、Abbot 和 SWTBot。

GUI code can and should be developed test-first as well. Some tools for rich-client unit testing are TestNG, Abbot, and SWTBot.

EasyMock 和 Ruby/Mock 等工具有助于实现模拟对象和测试存根，这是精心设计的单元测试的组成部分。

Tools such as EasyMock and Ruby/Mock help with implementing mock objects and test stubs, an integral part of well-designed unit tests.

程序员用来编写面向技术的测试的工具也可以用于面向业务的测试。它们是否适合您项目中的该目的取决于您的团队和客户的需求。

The tools programmers use to write technology-facing tests can also be used for business-facing tests. Whether they are suited for that purpose in your project depends on the needs of your team and your customers.

我们还可以使用我们的测试来提供开发团队和业务专家都能理解的通用语言。正如 Brian Marick [2008] 指出的那样，共享语言可以帮助业务人员设想他们想要的功能。它可以帮助程序员精心设计易于扩展的代码。可以表达期望和不期望行为的真实示例，以便业务和技术方面都能理解它们。具有不同背景和观点的人可以访问图片、流程图、电子表格和原型。我们可以使用这些工具来查找示例，然后轻松地将这些示例转化为测试。测试需要以业务用户可以理解的方式编写，但仍可由技术团队执行。

We can also use our tests to provide a common language that’s understood by both the development team and the business experts. As Brian Marick [2008] points out, a shared language helps the business people envision the features they want. It helps the programmers craft well-designed code that’s easy to extend. Real-life examples of desired and undesired behavior can be expressed so that they’re understood by both the business and technical sides. Pictures, flow diagrams, spreadsheets, and prototypes are accessible to people with different backgrounds and viewpoints. We can use these tools to find examples and then easily turn those examples into tests. The tests need to be written in a way that’s comprehensible to a business user reading them yet still executable by the technical team.

面向业务的测试还有助于定义范围，以便每个人都知道什么是故事的一部分，什么不是。许多测试框架现在允许团队创建领域语言并使用该语言定义测试。Fit（集成框架的功能）就是其中之一。

Business-facing tests also help define scope, so that everyone knows what is part of the story and what isn’t. Many of the test frameworks now allow teams to create a domain language and define tests using that language. Fit (Functional for Integrated Framework) is one of those.

可以说我们的客户会向我们提供我们需要的示例，以便我们了解每个故事应该传递的价值。但是，如果他们不知道如何解释他们想要的东西怎么办？在下一节中，我们将建议一些方法来帮助客户定义他们的满意度条件。

It’s fine to say that our customers will provide to us the examples that we need to have in order for us to understand the value that each story should deliver. But what if they don’t know how to explain what they want? In the next section, we’ll suggest ways to help customers define their conditions of satisfaction.

如果您曾经是要求特定软件功能的客户，您就会知道准确表达您想要什么是多么困难。通常，直到您能够看到、感觉到、触摸和使用它时，您才真正确切地知道自己想要什么。我们有很多方法可以帮助我们的客户弄清楚他们想要什么。

If you’ve ever been a customer requesting a particular software feature, you know how hard it is to articulate exactly what you want. Often, you don’t really know exactly what you want until you can see, feel, touch and use it. We have lots of ways to help our customers get clarity about what they want.

使用示例

最重要的是，请客户举例说明该功能应该如何工作。假设这个故事是关于从在线购物车中删除商品的。请客户在白板上画出删除功能的外观。他们是否需要任何额外的功能，例如确认步骤，或者有机会保存该项目以备日后取回？如果无法完成删除，他们希望看到什么？

Most importantly, ask the customer to give you examples of how the feature should work. Let’s say the story is about deleting items out of an online shopping cart. Ask the customer to draw a picture on a whiteboard of how that delete function might look. Do they want any extra features, such as a confirmation step, or a chance to save the item in case they want to retrieve it later? What would they expect to see if the deletion couldn’t be done?

示例可以构成我们测试的基础。我们的挑战是捕获可能用业务领域语言表达的示例，作为可以实际执行的测试。有些客户很乐意使用 Fit 或 FitNesse 等测试工具来表达示例，只要他们可以用他们的领域语言编写示例即可。

Examples can form the basis for our tests. Our challenge is to capture examples, which might be expressed in the business domain language, as tests that can actually be executed. Some customers are comfortable expressing examples using a test tool such as Fit or FitNesse as long as they can write them in their domain language.

让我们用一个简单的故事来探究示例和测试之间的区别（见图8-4）。人们经常混淆这两个术语。

Let’s explore the difference between an example and a test with a simple story (see Figure 8-4). People often get confused between these two terms.

图 8-4用作示例和测试基础的故事

Figure 8-4 Story to use as a base for examples and tests

一个例子看起来像这样：

An example would look something like this:

一页上有 5 个项目。我想选择 20.25 美元的商品 1 并将其放入购物车。我单击下一页，其中还有 5 个项目。我在该页面上以 5.38 美元选择了第二件商品，并将其放入我的购物车。当我说我完成购物时，它会同时显示来自我购物车中第一页和第二页的商品，总计 25.63 美元

There are 5 items on a page. I want to select item 1 for $20.25 and put it in the shopping cart. I click to the next page, which has 5 more items. I select a second item on that page for $5.38 and put it in my shopping cart. When I say I’m done shopping, it will show both the item from the first page and the item from the second page in my shopping cart, with the total of $25.63

测试可能会有很大不同。我们将使用表 8-1中的 Fit 类型格式来向您展示如何表示测试。

The test could be quite a bit different. We’ll use a Fit type format in Table 8-1 to show you how the test could be represented.

表 8-1故事 PA-2 的测试

Table 8-1 Test for Story PA-2

该测试以可执行格式捕获示例。它可能不会使用完全相同的输入，但它封装了示例用户场景。可以编写更多测试用例来测试边界条件、边缘用例和其他场景。

The test captures the example in an executable format. It might not use exactly the same inputs, but it encapsulates the sample user scenario. More test cases can be written to test boundary conditions, edge cases, and other scenarios.

如果您的客户团队由来自组织不同部门的人员组成，那么他们之间可能对特定故事的确切意图存在冲突意见。在丽莎的公司，业务发展要产生收入的功能，运营需要减少电话支持电话的功能，财务需要简化会计、现金管理和报告的功能。令人惊讶的是，不同观点的人可以对同一个故事做出如此多的独特解释。

If your customer team consists of people from different parts of the organization, there may be conflicting opinions among them about exactly what’s intended by a particular story. In Lisa’s company, business development wants features that generate revenue, operations wants features that cut down on phone support calls, and finance wants features that streamline accounting, cash management, and reporting. It’s amazing how many unique interpretations of the same story can emerge from people who have differing viewpoints.

产品负责人是 Scrum 中的一个角色。他不仅负责实现预先的清晰度，而且还负责在确定故事优先级时充当“客户代表”。不过有一个缺点。当您通过一个人汇集许多不同观点的需求时，可能会丢失一些东西。理想情况下，开发团队应该与客户团队坐在一起，学习如何完成客户的工作。如果我们充分了解客户的需求以执行其日常任务，我们就有更好的机会开发出能够正确支持这些任务的软件。

A Product Owner is a role in Scrum. He’s responsible not only for achieving advance clarity but also for acting as the “customer representative” in prioritizing stories. There’s a downside, though. When you funnel the needs of many different viewpoints through one person, something can be lost. Ideally, the development team should sit together with the customer team and learn how to do the customer’s work. If we understand the customer’s needs well enough to perform its daily tasks, we have a much better chance of producing software that properly supports those tasks.

无论您的团队选择汇集不同的观点，重要的是只有“客户的一个声音”呈现给团队。

However your team chooses to bring together varying viewpoints, it is important that there is only “one voice of the customer” presented to the team.

我们说产品所有者提供满意的条件。让我们更仔细地看看我们的意思。

We said that product owners provide conditions of satisfaction. Let’s look more closely at what we mean.

整个发行版以及每个功能或故事都有令人满意的条件。验收测试有助于定义故事验收。除非预先同意故事的满足条件，否则您的开发团队无法成功交付业务所需的内容。客户团队需要“用同一个声音说话”。如果您从不同的利益相关者那里得到不同的要求，您可能需要推迟并推迟故事，直到您有一个明确的业务满意度条件列表。请客户代表提供每个故事的最少信息量，以便您可以通过富有成效的对话开始每次迭代。

There are conditions of satisfaction for the whole release as well as for each feature or story. Acceptance tests help define the story acceptance. Your development team can’t successfully deliver what the business wants unless conditions of satisfaction for a story are agreed to up front. The customer team needs to “speak with one voice.” If you’re getting different requirements from different stakeholders, you might need to push back and put off the story until you have a firm list of business satisfaction conditions. Ask the customer representative to provide a minimum amount of information on each story so that you can start every iteration with a productive conversation.

了解客户团队要求的最好方法是与客户面对面交谈。因为每个人都在与“需求”作斗争，所以有一些工具可以帮助客户团队完成每个故事。满意的条件不仅应包括故事所传达的特征，还应包括对更大系统的影响。

The best way to understand the customer team’s requirements is to talk with the customers face to face. Because everyone struggles with “requirements,” there are tools to help the customer team work through each story. Conditions of satisfaction should include not only the features that the story delivers but also the impacts on the larger system.

Lisa 的产品负责人使用清单格式来解决以下问题：

Lisa’s product owner uses a checklist format to sort out issues such as:

产品所有者使用模板将此信息放在团队的 wiki 上，以便团队成员了解故事和开始编写测试时可以使用它。

The product owner uses a template to put this information on the team’s wiki so that it can be used as team members learn about the stories and start writing tests.

这些条件基于客户团队为故事所做的关键假设和决策。他们通常来自与客户就每个故事的高级验收标准进行的对话。讨论满意度条件有助于识别有风险的假设，并增加团队编写和正确估计完成故事所需的所有任务的信心。

These conditions are based on key assumptions and decisions made by the customer team for a story. They generally come out of conversations with the customer about high-level acceptance criteria for each story. Discussing conditions of satisfaction helps identify risky assumptions and increases the team’s confidence in writing and correctly estimating all of the tasks that are needed to complete the story.

在敏捷开发中，我们一次只关注一个故事。每个故事通常是整个应用程序的一个小组成部分，但它可能会产生很大的连锁反应。一个新故事就像一块小石头掉入应用程序的水中，我们可能不会考虑由此产生的波浪会遇到什么。当我们在每次迭代中专注于少数故事时，很容易忘记大局。

In agile development, we focus on one story at a time. Each story is usually a small component of the overall application, but it might have a big ripple effect. A new story drops like a little stone into the application water, and we might not think about what the resulting waves might run into. It’s easy to lose track of the big picture when we’re focusing on a small number of stories in each iteration.

Lisa 的团队发现列出系统中可能受故事影响的所有部分很有帮助。团队可以检查每个“测试点”以查看它可能生成的需求和测试用例。一个小而无辜的故事可能会产生广泛的影响，它所涉及的应用程序的每个部分都可能呈现出另一个层次的复杂性。您需要了解任何代码更改的所有潜在影响。列一个清单是一个很好的起点。在迭代的前几天，团队可以进一步研究和分析受影响的区域，看看是否需要更多的任务卡来覆盖所有这些区域。

Lisa’s team finds it helpful to make a list of all of the parts of the system that might be affected by a story. The team can check each “test point” to see what requirements and test cases it might generate. A small and innocent story might have a wide-ranging impact, and each part of the application that it touches might present another level of complexity. You need to be aware of all the potential impacts of any code change. Making a list is a good place to start. In the first few days of the iteration, the team can research and analyze affected areas further and see whether any more task cards are needed to cover them all.

看起来很小但会影响系统意外区域的故事可能会反过来咬你一口。如果您的团队忘记考虑所有依赖关系，并且如果新代码与现有功能相交，您的故事可能需要比计划更长的时间才能完成。确保您的故事测试包括实施新功能时不太明显的后果。

Stories that look small but that impact unexpected areas of the system can come back to bite you. If your team forgets to consider all dependencies, and if the new code intersects with existing functionality, your story might take much longer than planned to finish. Make sure your story tests include the less obvious fallout from implementing the new functionality.

花时间确定每个故事提供的核心价值，并找出一种渐进的方法来开发它。计划编写测试、编写代码和测试代码的小增量。这样，您的象限 2 测试可确保您按计划交付最小值。

Take time to identify the central value each story provides and figure out an incremental approach to developing it. Plan small increments of writing tests, writing code, and testing the code some more. This way, your Quadrant 2 tests ensure you’ll deliver the minimum value as planned.

清单是产品所有者确保他们正确评估和传达故事所有方面的一种方式。Lisa 团队的产品负责人 Steve Perkins 提出了他自己的“故事清单”，以确保他和利益相关者仔细考虑受故事影响的一切。为此，他在团队 wiki 上创建了一个模板。清单指定了满意的条件——业务需要从故事中得到什么。它还包括对现有功能的影响，例如网站、文件、管理表格、账户报表和系统的其他组件以及业务的日常运营。清单确保团队不会因为忘记考虑而错过诸如数据迁移、通知、法律考虑以及与供应商和业务合作伙伴的沟通等要求。图 9-1显示了一个示例故事清单。

Checklists are one way for product owners to make sure they correctly assess and communicate all of the aspects of a story. The product owner for Lisa’s team, Steve Perkins, came up with his own “story checklist” to make sure he and the stakeholders think through everything affected by the story. He created a template on the team wiki for this purpose. The checklist specifies the conditions of satisfaction—what the business needs from the story. It also includes impacts on existing functions such as the website, documents, administrative forms, account statements, and other components of the system and the daily operation of the business. The checklist makes sure the team doesn’t miss requirements such as data migration, notifications, legal considerations, and communications to vendors and business partners because they forgot to consider them. Figure 9-1 shows a sample story checklist.

图 9-1样本故事清单

Figure 9-1 Sample story checklist

思维导图是一种简单但有效的方法，可以用来找出您在简单的头脑风暴会议中可能不会想到的想法。思维导图是为表示与中心关键概念相关联的概念、词语或想法而创建的图表。我们使用思维导图来组织这本书。

Mind maps are a simple but effective way to search out ideas that that might not occur to you in a simple brainstorming session. Mind maps are diagrams created to represent concepts, words, or ideas linked to a central key concept. We used mind maps to organize this book.

无论您是购买我们使用的工具还是在白板或大纸上绘图，这都无关紧要。效果是一样的。思维导图使您能够以与您思考问题的方式一致的方式产生想法和工作。

It really doesn’t matter whether you purchase a tool such as the one we used or draw on a whiteboard or a big piece of paper. The effect is the same. Mind maps enable you to generate ideas and work in a way that is consistent with the way you think about problems.

举个例子怎么样？我们正在讨论图 9-2中所示的故事。

How about an example? We’re discussing the story shown in Figure 9-2.

图 9-2购物车删除故事

Figure 9-2 Shopping cart delete story

我们聚集在白板周围，开始提问。删除的项目应该去哪里？它们应该被保存以供以后批准，还是应该消失？删除项目后屏幕应该是什么样的？图 9-3显示了我们可能在白板上绘制的思维导图类型的示例。

We gather around the whiteboard and start asking questions. Where should the deleted items go? Should they be saved for later approval, or should they just disappear? What should the screen look like after we delete an item? Figure 9-3 shows an example of the sort of mind map we might draw on a whiteboard.

图 9-3购物车删除故事的示例思维导图

Figure 9-3 Example mind map for shopping cart delete story

如果可能，用于指定面向业务的测试的工具应该适合您的业务领域。例如，电子表格被金融服务公司广泛使用，因此对于金融服务领域的项目，使用电子表格来定义故事应该提供的功能示例是有意义的。

When possible, tools for specifying business-facing tests should fit well with your business domain. For example, spreadsheets are widely used by financial services companies, so for a project in the financial services area it makes sense to use spreadsheets to define examples of the functionality that a story should deliver.

客户可以编写一些高级测试用例来帮助在迭代开始之前完善故事，可能使用某种类型的检查表。一些客户团队只是在每张故事卡的背面写几个测试，可能是一个快乐的路径和一个负面的测试。有些人会在电子表格或他们喜欢使用的任何格式中编写更详细的示例。

Customers can write a few high-level test cases to help round out a story prior to the start of the iteration, possibly using some type of checklist. Some customer teams simply write a couple of tests, maybe a happy path and a negative test, on the back of each story card. Some write more detailed examples in spreadsheets or whatever format they’re comfortable working with.

Lisa 团队的产品负责人 Steve Perkins 经常在电子表格中说明复杂的计算和算法，团队可以稍后将其转化为测试。图 9-4显示了他的一个工作表，该工作表对输入值执行计算以生成 ADR 和 ACR 列中的值。这种格式很容易进入自动化测试框架（相应的 FitNesse 示例参见图 9-8 ）。

Steve Perkins, the product owner for Lisa’s team, often illustrates complex calculations and algorithms in spreadsheets, which the team can turn into tests later. Figure 9-4 shows one of his worksheets, which performs calculations on the input values to produce the values in the ADR and ACR columns. This format is easy to get into an automated test framework (refer to Figure 9-8 for the corresponding FitNesse example).

图 9-4来自产品负责人的电子表格示例

Figure 9-4 Spreadsheet example from product owner

查看您的业务专家已经使用的工具，看看它们是否可以调整以记录所需功能行为的示例，以帮助开发团队更好地理解故事。

Look at tools already used by your business experts and see whether they can be adapted to document examples of desired feature behavior to help the development team better understand the story.

Janet 曾与多个使用电子表格作为 Fit 测试输入的团队合作。这允许客户使用他们熟悉的工具工作，但不会浪费任何精力将它们转换为自动化工具。

Janet has worked with several teams that have used spreadsheets as input into their Fit tests. This allows customers to work in a tool that is familiar to them but not waste any effort in translating them to an automation tool.

模型可以采用多种形式。纸质原型是测试屏幕如何协同工作的一种简单但有效的方法。在白板上画图可以达到同样的目的，但不能传来传去。现有应用程序的屏幕截图可以构成讨论如何添加新功能以及新功能适合 UI 的位置的基础。您可能在其他开发方法中使用过此类工具。敏捷开发的最大区别在于我们在开始编写代码时创建和讨论模型，而不是提前数周或数月。我们可以确信模型代表了客户现在的需求。

Mock-ups can take many forms. Paper prototypes are a simple but effective way to test how screens will work together. Drawing on a whiteboard can accomplish the same goal, but it can’t be passed around. Screenshots from existing applications can form the basis of a discussion about how to add a new feature and where it will fit into the UI. You may have used tools like these in other development methodologies. The big difference in agile development is that we create and discuss the mock-ups just as we’re about to start writing the code, rather than weeks or months beforehand. We can be confident that the mock-up represents what the customers want right now.

图 9-5显示了 Lisa 的团队用来模拟新报告的模型示例——只需标记一个相似的现有报告即可。

Figure 9-5 shows an example of a mock-up that Lisa’s team used to mock up a new report—simply by marking up an existing report that’s similar.

图 9-5示例报告模型

Figure 9-5 Sample report mock-up

模型不需要花哨或漂亮，也不需要花费很多时间来创建。它们确实需要让客户和开发团队都能理解。

Mock-ups don’t need to be fancy or pretty, or to take a lot of time to create. They do need to be understandable to both the customer and developer teams.

简单的图表工具很有用，无论团队是否在同一地点。以更永久的形式捕获讨论期间制定的工作流或决策树通常是个好主意。流程图可以成为用户场景的基础，可以帮助您将两个或三个用户故事联系在一起。让我们再看看我们在第 8 章中介绍的装运订单故事（见图9-6）。

Simple diagramming tools are helpful, whether the team is co-located or not. It’s often a good idea to capture in a more permanent form a workflow or decision tree worked out during a discussion. Flow diagrams can become the basis of a user scenario that might help you tie two or three user stories together. Let’s look at the shipping order story again that we introduced in Chapter 8 (see Figure 9-6).

图 9-6运费故事

Figure 9-6 Story for shipping charges

图 9-7显示了一个非常简单的决策过程流程图，该过程根据阈值订单金额确定客户的订单是否符合免费送货条件。因为我们已经与我们的客户讨论过这个故事，所以我们发现客户的订单不仅必须超过美元金额阈值，而且必须只发送到一个地址，而且它的重量必须小于运输重量阈值。如果满足所有这些条件，客户的订单将免费发货；否则，客户将不得不从“选择运输选项”页面进行选择。

Figure 9-7 shows a very simple flowchart of a decision process for whether a customer’s order is eligible for free shipping based on a threshold order amount. Because we’ve discussed this story with our customer, we’ve found out that the customer’s order must not only exceed a threshold dollar amount but also must be to one address only, and it must weigh less than a shipping weight threshold. If all of these conditions are satisfied, the customer’s order will ship free; otherwise, the customer will have to select from the “choose shipping options” page.

图 9-7获得免费送货选项资格的流程图

Figure 9-7 Flow chart for qualifying for free shipping option

流程图和思维导图等视觉效果是描述故事功能概览的好方法，尤其是当它们由一组客户、程序员和测试人员绘制时。在敏捷开发中，我们在开始编写测试和代码时创建这些图表。根据这些，团队可以立即开始深入挖掘详细需求。

Visuals such as flow diagrams and mind maps are good ways to describe an overview of a story’s functionality, especially if they’re drawn by a group of customers, programmers, and testers. In agile development, we create these diagrams as we’re about to start writing tests and code. From these, the team can immediately start digging down to the detailed requirements.

如果我们与客户处于不同的位置，我们需要工具来帮助我们与他们交谈。分布式团队告诉我们，桌面共享是帮助他们处理在不同地点工作的首要工具。Windows NetMeeting 和 VNC 是让两个团队成员在不同位置进行配对测试的工具示例。WebEx 和 Skype 等视频会议工具支持远程团队和客户之间的协作和演示。Scriblink 等在线白板和 Mimeo 等交互式白板工具有助于分布式白板讨论。

If we’re in a different location than our customers, we need tools to help us converse with them. Distributed teams tell us that desktop sharing is the number one tool that helps them deal with working in separate locations. Windows NetMeeting and VNC are examples of tools that let two team members in different locations pair-test. Video conferencing tools such as WebEx and Skype enable collaboration and demos between remote teams and customers. Online whiteboards such as Scriblink and interactive whiteboard tools such as Mimeo facilitate distributed whiteboard discussions.

更多适合产品所有者和业务专家直接使用的工具正在变得可用，并且许多团队开发了自己的工具。Fit（集成测试框架）和 FitNesse 等工具旨在促进客户与开发团队之间的协作和沟通。我们听说有更多团队的客户实际使用诸如此类的工具编写测试。

More tools that are geared for direct use by product owners and business experts are becoming available, and many teams develop their own. Tools such as Fit (Framework for Integrated Tests) and FitNesse were designed to facilitate collaboration and communication between the customer and development teams. We’re hearing about more teams where the customers actually write the tests in a tool such as those.

一些团队构建自己的框架，允许客户、业务分析师和测试人员记录可以直接转化为可执行测试的示例。这些通常基于开源工具，例如 xUnit、Fit、Selenium 和 Watir。我们喜欢这种方法，因为它可以节省时间和资源。当您在短迭代中交付生产就绪代码时，您需要一个简化的流程。

Some teams build their own frameworks that allow customers, business analysts, and testers to document examples that can be directly turned into executable tests. These are often based on open source tools such as xUnit, Fit, Selenium, and Watir. We like this approach, because it saves time and resources. When you’re delivering production-ready code in short iterations, you need a streamlined process.

在线论坛工具是电子邮件对话的一个很好的替代方案，可以持续讨论功能或技术问题，尤其是对于并非所有人都坐在一起的团队。电子邮件经常被遗漏或丢失，人们必须记住选择“全部回复”，而且以后很难整理讨论的细节。Lisa 的团队使用在线论坛来征求对不同工具的意见，为功能提出不同的行为，并进行哲学讨论，例如是否跟踪缺陷。

Online forum tools are a good alternative to email conversations for ongoing discussions about features or technical concerns, especially for teams that don’t all sit together. Emails often get missed or lost, people have to remember to choose “Reply all,” and it can be hard to put together the details of the discussion later. Lisa’s team uses an online forum to elicit opinions about different tools, propose different behavior for features, and conduct philosophical discussions such as whether to track defects.

找到合适的电子工具对于分布式团队尤为重要。即时消息、电话、VoIP 和 Skype 帮助我们进行交流，但它们缺乏可视化组件。一些全球团队要求他们的成员在非标准时间开会，以便他们可以进行实时对话，但书面和视觉交流的框架仍然至关重要。

Finding the right electronic tools is particularly vital for distributed teams. Instant messaging, the telephone, VoIP, and Skype help us communicate, but they lack the visual component. Some global teams ask their members to meet at nonstandard hours so that they can have real-time conversations, but frameworks for written and visual communication are still critical.

Wiki 是一种常用工具，用于加强交流和记录讨论和决策。Wiki 使用户能够在 Web 浏览器中编辑网页内容。用户可以添加超链接并轻松创建新页面。您可以上传白板绘图的模型、示例和图片，并使它们在 Wiki 页面上易于显示。分层组织可能难以维护，但是有许多可用的开源和供应商 wiki 软件包可以使管理您的知识库和共享信息更容易管理。如果您的 wiki 知识库已经发展到难以找到任何东西的地步，请聘请技术作家将其转化为有条理的可用文档。

Wikis are a common tool used to enhance communication and record discussions and decisions. Wikis enable users to edit web page content in a web browser. Users can add hyperlinks and easily create new pages. You can upload mock-ups, samples, and pictures of whiteboard drawings and make them easily visible on Wiki pages. The hierarchical organization can get tricky to maintain, but there are lots of open source and vendor wiki software packages available that make managing your knowledgebase and sharing information easier to administer. If your wiki knowledgebase has grown to the point where it’s hard to find anything, hire a technical writer to transform it into organized, usable documentation.

开源和商业工具提供了让团队在线协作处理需求和测试用例的方法。我们怎么强调都不够强调您需要确定可能有用的工具，对它们进行几次迭代试验，并确定它们对您的工作效果如何。您团队的需求会随着时间而改变，因此请始终乐于尝试新技术和框架。

Open source and commercial tools provide ways to let teams collaborate on requirements and test cases online. We can’t emphasize enough the need for you to identify tools that might be helpful, to experiment with them for a few iterations, and to decide how well they work for you. Your team’s needs will change with time, so always be open to trying new techniques and frameworks.

这些工具有助于创建关于故事的对话。借助这些技术，以及尽可能多的实时对话和视觉共享，我们可以从一开始就定义正确的产品。

These tools help create the conversation about the story. With these techniques, and as much real-time conversation and visual sharing as we can manage, we can define the right product from the get-go.

有许多开源工具可让您在 GUI 下或 API 层进行测试。我们仅列出了几个，但您的团队需要为您确定合适的工具。

There are a multitude of open source tools that enable you to test below the GUI or at the API layer. We are listing just a few, but your team will need to determine the right tool for you.

API层功能测试工具

在 Lisa 加入她的第一个敏捷团队之前，“在 GUI 后面”进行测试是一个听起来不错的概念，但她从未有机会尝试过。Fit 和建立在 Fit 之上的 FitNesse 是功能测试工具，源于客户团队需要能够编写和理解推动开发的面向业务的测试。使用这些工具，团队可以在不涉及表示层的情况下测试业务逻辑。

Before Lisa joined her first agile team, testing “behind the GUI” was a concept that sounded good, but she’d never had the opportunity to try it. Fit, and FitNesse, which is built on top of Fit, are functional test tools that grew from the need for the customer team to be able to write and understand the business-facing tests that drive development. With these tools, teams can test business logic without involving the presentation layer.

Fit 和 FitNesse。Fit (Framework for Integrated Tests) 是一个促进协作的开源测试框架，这使其成为帮助细化需求的好工具。Fit 是 Ward Cunningham 的发明，享有杰出的开发人员名单。Fit 使客户、测试人员和程序员能够使用示例来指定他们期望系统执行的操作。测试运行时，Fit 会自动将客户的期望值与实际结果进行比较。

Fit and FitNesse. Fit (Framework for Integrated Tests) is an open source testing framework that promotes collaboration, which makes it a good tool to help refine requirements. The invention of Ward Cunningham, Fit has enjoyed an illustrious roster of contributing developers. Fit enables customers, testers, and programmers to use examples to specify what they expect the system to do. When the tests run, Fit automatically compares customers’ expectations to actual results.

借助 Fit，客户可以使用他们的主题专业知识提供指导，以定义程序员可以编码的示例。程序员通过编写对示例进行实际检查的固定装置来参与。这些装置使用示例中指定的数据与实际程序一起运行。

With Fit, customers can provide guidance using their subject matter expertise to define the examples that the programmers can code against. The programmers participate by writing the fixtures that do the actual checks against the examples. These fixtures use the data specified in the examples to run with the actual program.

适合性测试由将测试输入传递给生产代码然后接受输出并与预期结果进行比较的夹具自动执行。测试结果用颜色编码，因此很容易发现故障或异常。

Fit tests are automated by fixtures that pass the test inputs to the production code and then accept the outputs, which it then compares with expected results. The test results are color-coded, so it’s easy to spot a failure or exception.

Fit 测试以 HTML 表格的形式编写，但团队可以自定义 Fit，以便可以将测试编写为电子表格或客户、测试人员和分析师认为可用的任何形式。

Fit tests are written as HTML tables, but teams can customize Fit so that tests can be written in spreadsheets or whatever form the customers, testers, and analysts find usable.

在fit.c2.com上了解有关 Fit 的更多信息。

Learn more about Fit at fit.c2.com.

FitNesse 是一个基于 Fit 的 Web 服务器、wiki 和软件测试工具。最初由 Robert C. “Uncle Bob” Martin 和 Micah Martin 开发，它是一个拥有活跃开发者社区的开源工具。FitNesse 和 Fit 之间的主要区别是 FitNesse 测试是用 wiki 标记而不是 HTML 表格编写的，一些用户认为后者更容易。它还支持在电子表格中创建测试并将其导入到测试中。

FitNesse is a web server, a wiki, and a software testing tool that is based on Fit. Originally developed by Robert C. “Uncle Bob” Martin and Micah Martin, it’s an open source tool with an active developer community. The main difference between FitNesse and Fit is that FitNesse tests are written in wiki markup instead of HTML tables, which some users find easier. It also supports creating tests in spreadsheets and importing those into the tests.

在www.fitnesse.org上了解有关 FitNesse 的更多信息。

Learn more about FitNesse at www.fitnesse.org.

图 9-8显示了从图 9-4中的示例构建的 FitNesse 测试的一部分。添加了更多输入以使生产代码运行，但基本测试数据来自电子表格。测试结果通过时颜色编码为绿色，失败时为红色。

Figure 9-8 shows part of the FitNesse test that was built from the example in Figure 9-4. More inputs were added to make the production code run, but the essential test data is from the spreadsheet. The test results are color-coded green when they pass, red when they fail.

图 9-8来自客户示例的自动 FitNesse 测试

Figure 9-8 Automated FitNesse test from customer example

Fit 或 FitNesse 类型的工具的另一个好处是它促进不同团队成员之间的协作，以便提出正确的测试来指导发展。客户、程序员、测试人员和其他人一起工作来指定和自动化测试。

Another benefit of a Fit or FitNesse type of tool is that it promotes collaboration among different team members in order to come up with the right tests to guide development. Customers, programmers, testers, and others work together to specify and automate the tests.

测试网络服务。Web 服务只是 API 的另一种形式，它使其他应用程序能够访问您的应用程序。让我们谈谈可用于测试系统各种输入的一些工具。

Testing Web Services. Web services is just another form of an API that enables other applications to access your application. Let’s talk about some of the tools you can use to test various inputs into your system.

交叉检查。CrossCheck 是一种用于测试 Web 服务的工具示例。您提供WSDL（Web 服务描述语言）；CrossCheck 编译该页面，然后为您呈现一个选项卡式菜单，其中包含供您填写的文本框。它有一个运行模式，您可以在其中将测试添加到套件中，然后运行该套件。Lisa 和 Janet 都没有尝试过这个工具，但是在 Yahoo 敏捷测试组中，它被认为是一个用于测试 Web 服务的工具，如果你每次都运行相同的数据的话。

CrossCheck. CrossCheck is one example of a tool for testing web services. You supply the WSDL (Web Services Description Language); CrossCheck compiles the page and then presents you with a tabbed menu that contains textboxes for you to fill in. It has a Run mode where you can add your tests to a suite and then run the suite. Neither Lisa or Janet have tried this tool, but it was noted on the Yahoo agile-testing group as a tool to use for testing web services if you were running the same data through each time.

Ruby 测试::单元。Janet 参与的一个项目使用 Ruby 的单元测试框架 Test::Unit 来测试 Web 服务，并取得了巨大成功。事实上，该团队能够尽早进行测试，为程序员提供即时反馈，这有助于最终设计。

Ruby Test::Unit. One project Janet was on used Ruby’s unit testing framework, Test::Unit, to test web services, with great success. In fact, the team was able to test early to give the programmers immediate feedback, which helped with the final design.

请参阅第 12 章“测试象限总结”中的“系统测试”示例，了解 Janet 的团队如何使用 Ruby Test::Unit 来测试 Web 服务。

See the “System Test” example in Chapter 12, “Summary of Testing Quadrants,” to see how Janet’s team used Ruby Test::Unit to test web services.

肥皂用户界面。建议用于测试 Web 服务的另一个工具是 soapUI。它具有陡峭的学习曲线，但可用于性能和负载测试。因为它可以遍历 Excel 电子表格或文本文件中的行，所以它可以用于数据驱动的测试。

soapUI.Another tool suggested for testing web services is soapUI. It has a steep learning curve but can be used for performance and load testing. Because it can loop though rows in an Excel spreadsheet or text file, it can be used for data-driven testing.

在表示层以下的层工作的测试非常适合编写和自动化指导编码的客户测试。一些从业者还没有从故事测试驱动开发中获得他们期望的价值。Brian Marick [ 2008 ] 假设使用程序员测试驱动开发构建的应用程序、大量示例的面向业务的设计严重依赖于白板讨论、一小组自动完整性测试和大量探索性测试可能更便宜且同样有效的方法。无论采用哪种方法，如果您要测试带有用户界面的应用程序，您都需要在 GUI 级别实现一些自动化。

Tests that work at the layers below the presentation layer are well suited for writing and automating customer tests that guide coding. Some practitioners haven’t gotten the value they expected from story test-driven development. Brian Marick [2008] hypothesized that an application built with programmer test-driven development, example-heavy business-facing design that relies heavily on whiteboard discussions, a small set of automated sanity tests, and lots of exploratory testing could be a less expensive and equally effective approach. Whichever approach you take, if you’re testing an application with a user interface, you’ll need some automation at the GUI level.

等一下。我们如何使用 GUI 测试来驱动开发，因为 GUI 在故事完成之前不会准备好？这听起来有悖常理，但自动化 GUI 测试对我们开发新功能非常重要。测试框架可用于在编写代码之前为 GUI 工具指定测试用例。此外，您可以在之前自动化 GUI 测试通过使用 HTML 模型或通过所有屏幕开发一个端到端的准系统切片来完成编码，这些屏幕只是简单地导航但尚未提供所有功能。即使您没有使用大量自动化故事测试来推动开发，但如果没有自动化的任何帮助，帮助我们了解功能并提供即时反馈的手动探索性测试也会变得非常乏味和缓慢。让我们看看有助于使用面向业务的测试推动开发的 GUI 测试工具的类型。

Wait a minute. How can we use GUI tests to drive development, because the GUI won’t be ready until the story is complete? It sound counterintuitive, but automated GUI tests are important to help us while we’re developing new functionality. Test frameworks can be used to specify test cases for a GUI tool before the code is written. In addition, you can automate GUI tests before coding is finished, either by using HTML mock-ups or by developing an end-to-end bare-bones slice through all of the screens that simply navigates but doesn’t provide all of the functionality yet. Even if you’re not using a lot of automated story tests to drive development, manual exploratory testing that helps us learn about the functionality and provides immediate feedback gets pretty tedious and slow without any assistance from automation. Let’s look at the types of GUI test tools that help drive development using business-facing tests.